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The  security  kernel  technology  has  provided  the  technical 
foundation  for  highly  reliable  protection  of  computerized 
information.  However,  the  operating  system  implementations 
face  two  significant  challenges:  providing  (1)  adequate 

computational  resources  for  applications  tasks,  and  (2)  a 
clean,  straightforward  structure  whose  correctness  can  be 
easily  reviewed.  This  paper  presents  the  experience  of  an 
ongoing  security  kernel  implementation  using  the  Advanced 
nicro  Devices  4116  single-board  computer  based  on  the  Z8002 
microprocessor.  The  performance  issues  of  process  switch¬ 
ing,  domain  changing,  and  multiprocessor  bus  contention  are 
explicitly  addressed.  The  strictly  hierarchical  (i.e.. 
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loop-free)  structure  provides  a  series  of  increasingly  capa- 
i  ble,  separately  usable  operating  systee  subsets.  Security 

enforceeeat  is  structured  in  two  layers:  the  basic  kernel 

rigorously  enforces  a  non- discretionary  (viz.,  lattice  mo- 
del)  policy,  vhila  an  upper  layer  provides  the  access  re¬ 
finements  for  a  discretionary  policy. 


fil£S£&.QS£fi 

For  the  last  tvo  and  a  half  years  the  Naval  Postgraduate 
School  has  been  conducting  a  research  and  developaent  pro¬ 
ject  involving  security  kernel  based  operating  systems  de¬ 
signed  for  multiple  processor  implementations.  As  this  work 
continues  «e  feel  that  it  is  important  to  report  on  our  pro¬ 
gress  and  experiences,  especially  in  the  area  of  micropro¬ 
cessor  implementations. 

This  effort  has  come  to  be  known  as  the  "SASS"  or  Secure 
Archival  Storage  System  project  [1].  In  fact,  this  is  a 
misnomer,  as  SASS  is  but  a  single  instance  of  a  more  general 
family  of  secure  operating  systems  designed  early  in  the 
project  (2].  While  SASS  has  been  the  object  of  the  majority 
of  the  research  reported  it  is  not  the  only  implementation. 
Another  operating  system  of  this  family  has  also  been  writ¬ 
ten  to  support  a  signal  processing  system  that  uses  multiple 
Intel  8086  processors  [3]. 
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SASS  has  been  our  principal  testbed  for  exploring  the  in- 
pleaentation  and  perforaance  issues  related  to  these  types 
of  operating  systeas.  SASS  itself  vas  designed  to  be  a  cob- 
prehensive  multiuser,  multilevel  secure  file  storage  systea. 
As  designed,  it  will  consist  of  a  snail  nuaber  of 
Z8000-based  [4]  single  board  computers  sharing  a  single  8ul- 
tibus  with  storage  devices  and  input/output  devices.  SASS 
will  interface  via  bidirectional  lines  to  a  nuaber  of  "host" 
systems,  as  illustrated  in  Figure  1.  SASS  will  provide  each 
host  with  a  hierarchical  file  systea.  This  systea  can  be 
used  to  store  and  retrieve  files,  and  share  files  with  other 
hosts.  This  design  will  allow  SASS  to  serve  as  a  central 
hub  of  a  data  secure  network  of  coaputers  with  diverse  se- 
curity  authorization  for  sensitive  inforaation.  SASS  pro¬ 
vides  archival,  shared  storage  while  insuring  that  each  in¬ 
terfaced  host  processor  can  access  only  that  inforaation 
appropriate  to  its  security  authorizations. 
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For  this  family  of  operating  systems  the  security  kernel 
technology  has  been  used  not  only  to  effect  security  but 
also  to  provide  the  underlying  organizational  framevork  for 
the  operating  systea.  The  S1SS,  one  aeaber  of  this  faaily, 
is  in  the  final  stages  of  iapleaentation.  This  development 
experience  has  highlighted  the  iaportance  of  several  fea¬ 
tures  that  are  key  to  this  faaily: 

-  The  pervasive,  yet  systeaatizing  impact  of  the  security 
kernel  aethodology  [5]. 

-  The  design  simplicity  that  accompanies  a  loop-free  mo¬ 
dularization  that  is  highly  compatible  with  the  resource 
sharing  and  aultiprograaaing  functions. 

-  The  significance  of  a  high  degree  of  configuration  in¬ 
dependence,  particularly  for  the  ability  to  use  the  latest 
aicroprocessors  for  testbed  iapleaentation. 

Independent  of  security,  this  particular  kernel  structure 
is  attractive  as  a  canonical  operating  systea  interface.  It 
appears  adequate  for  a  vide  range  of  functionality  and  ca¬ 
pacity,  and  it  evidences  a  high  degree  of  independence  froa 
hardvare  idiosyncrasies.  These  operating  systea  features 
will  be  discussed  further  belov. 
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Members  of  this  operating  system  family  are  organized 
with  three  distinct  extended  machine  layers:  (1)  the  secur¬ 
ity  kernel,  (2)  tha  supervisor*  and  (3)  the  applications. 
This  is  illustrated  in  Figure  2.  The  concept  of  a  hierarchy 
of  extended  machines  is,  to  be  sure,  not  new;  however*  the 
security  kernel  significantly  constrains  the  organization. 
In  particular,  for  reason  of  security  all  the  management  of 
physical  resources  must  be  within  the  kernel  itself.  Furth¬ 
ermore,  confidence  is  increased  by  keeping  the  kernel  as 
small  and  simple  as  possible.  This  means  that  ouch  of  what 
is  commonly  thought  of  as  the  operating  system  is  provided 
outside  the  kernel  in  the  supervisor  layer.  For  this  parti¬ 
cular  family  member  there  is  no  major  applications  layer 
(viz.,  within  SASS  itself),  since  the  applications  are  con¬ 
tained  in  the  individual  hosts. 

The  basic  family  of  operating  systems  requires  the  ker¬ 
nels  to  provide  extended  virtual  machines  that  specifically 
support  both  asynchronous  processes  and  segmented  address 
spaces,  Within  SASS*  the  kernel  virtualizes  processors,  all 
levels  of  storage,  and  input/output.  The  kernel  creates 
virtualized  objects  —  processes,  segments*  and  devices.  It 
is  this  "pure"  virtual  interface  that  is  attractive  as  the 
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basis  far  canonical  operating  system  features.  The  SASS  su¬ 
pervisor  is  in  turn  built  upon  the  kernel,  using  these  vir¬ 
tualized  objects  to  construct  the  file  system. 

Both  the  kernel  and  the  supervisor  have  certain  responsi¬ 
bilities  for  system  security.  The  kernel  manages  all  physi¬ 
cal  resources,  and  the  kernel  is  distributed  (i.e.,  includ¬ 
ed)  in  the  address  space  of  every  process.  At  this  level, 
isolation  of  the  kernel  —  protection  from  users  and  the  su¬ 
pervisor  —  must  be  provided  by  hardware  enforced  domains. 
The  design  of  the  system  is  strictly  hierarchical  (viz.,  the 
kernel  is  more  privileged  than  the  supervisor)  so  protection 
rings,  as  defined  for  Hultics  [6],  are  a  satisfactory  domain 
implementation. 

The  kernel  has  the  responsibility  for  the  enforcement  of 
access  limitations:  that  is,  the  kernel  provides  the  mechan¬ 
ism  for  supporting  non-discretionary  security  policy.  The 
SASS  kernel  can  support  any  such  policy  which  can  be  ex¬ 
pressed  by  a  lattice  of  access  classes  [7J.  Every  object  — 
process,  segment,  or  device  --  has  a  non-forgable  label  that 
denotes  its  access  class.  This  non-discretionary  security 
has  been  parameterized  in  SASS  such  that  exactly  one  module 
has  knowledge  of  the  interpretation  of  this  label  in  terms 
of  a  specific  policy.  Thus,  only  this  single  module  need  be 
tailored  to  support  a  particular  policy. 
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SASS  provides  discretionary  security  (shared  access 
vithin  the  bounds  of  non-discretionary  policy  based  on  indi¬ 
vidual  user  identification)  via  the  supervisor  and  the  file 
structure.  This  discretionary  security  is  completely  out¬ 
side  of  the  kernel  (in  contrast  with  the  KSOS  [8]  approach). 

The  supervisor  handles  the  "Secure  Sender- Writer  Problem" 
with  a  non-exclusionary  approach  (one  writer,  retry  on  read) 
to  provide  synchronization  between  processes  of  different 
access  classes.  This  control  of  interprocess  communication 
is  implemented  via  kernel  primitives  using  Heed’s  event- 
counts  and  sequencers  [9]. 

The  SASS  supervisor  capabilities  are  achieved  by  associ¬ 
ating  two  processes  with  each  host  link.  These  processes 
access  that  portion  of  the  SASS  file  structure  associated 
with  that  host.  One  of  these  processes  provides  I/O  tran¬ 
smission  and  link  management,  while  the  other,  a  file  manag¬ 
er,  is  responsible  for  the  file  system  structure  of  its  as¬ 
sociated  host.  Communication  between  these  processes  (as  is 
communication  between  all  processes)  is  achieved  using 
shared  segments  —  a  mailbox.  Synchronization  is  provided 
by  the  kernel  (with  eventcounts  and  seguencers) . 

The  complementary  kernel/supervisor  approach  to  security 
has  several  advantages  for  SASS:  the  size  and  the  complexi- 
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ty  of  the  kernel  can  be  ainiaized,  and,  given  reliable  host 
authentication,  any  host  weaknesses  will  not  iapact  the  re¬ 
liable  enforceaeat  of  the  non-discretionary  security  policy. 


The  security  kernel  approach  constrains  not  only  the  in¬ 
terface  but  also  the  detailed  design  and  iapleaentation  of 
internal  state  variables.  The  problea  is  to  prevent  indi¬ 
rect  inforaation  paths  between  processes  with  different  ac¬ 
cess  classes.  He  address  this  problea  using  essentially  the 
approach  detailed  by  Hillen  [10],  although  without  the  rigor 
of  a  proof.  Internal  state  variables,  e.g.,  shared  resource 
tables,  are  assigned  an  access  class,  and  it  is  confiraed 
that  its  values  will  not  be  reflected  to  processes  of  an  in¬ 
consistent  access  class.  The  aost  apparent  result  is  that 
the  "success  code"  (returned  in  response  to  the  invocation 
of  kernel  priaitives)  priaarily  reflects  the  state  of  the 
per-process  virtual  resources,  not  the  shared  physical  re¬ 
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Another  aspect  of  the  design  that  has  helped  to  keep  the 
security  kernel  simple  and  understandable  is  the  loop-free 
structure  of  SASS.  The  loop-free  design  supports  the  soft¬ 
ware  engineering  concept  of  "inf orsation  hiding1*  £11],  as 
there  are  really  no  global  data  structures  within  SASS.  The 
kernel  is  internally  organized  into  four  distinct  layers,  as 
illustrated  in  Figure  3;  these  layers,  that  will  be  de¬ 
scribed  below,  are  terned  (1)  segsent  and  event  managers, 
(2)  traffic  controller,  (3)  memory  manager,  and  (4)  inner 
traffic  controller. 

In  practice  we  have  been  quite  doctrinaire  in  enforcement 
of  the  loop-free  structure  for  this  organization.  Hhile 
many  operating  systems  claim  to  be  nodular  or  well-struc¬ 
tured,  we  empirically  validate  this  claim.  He  "peel-off" 
the  upper  layers  one  at  a  time  by  literally  removing  the 
code  and  data,  and  then  demonstrate  that  the  remainder  can 
be  loaded  and  run  as  a  functionally  intact,  but  obviously 
limited,  operating  system  subset.  The  function  of  each  lay¬ 
er  will  now  be  described,  proceeding  from  the  bottom  upward. 
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l£H££  Ita££iS  Controller.  Processor  aultiplexing  has  two 
layers,  siailar  to  those  proposed  for  Hultics  [ 12].  Each 
physical  processor  has  a  fixed  nuaber  of  "virtual  proces¬ 
sors"  that  are  sultiplexed  onto  it.  Two  of  these  virtual 
processors  are  dedicated  to  systea  services:  an  idle  virtu¬ 
al  processor  and  a  aeaory  aanager  process  to  aanage  the  as¬ 
ynchronous  access  to  secondary  storage  devices.  The  reaain- 
ing  virtual  processors  (currently  two  per  physical 
processor)  are  available  to  the  (upper  level)  traffic  cont¬ 
roller.  The  inner  traffic  controller  provides  signal  and 
wait  synchronization  priaitives  that  include  a  aessage  that 
is  passed  between  virtual  processors.  In  teras  of  tradi¬ 
tional  -Jargon,  the  inner  traffic  controller  provides  aulti- 
prograaaing  by  scheduling  virtual  processors  to  run  on  the 
CPO  they  are  (peraanently)  associated  with.  Note  that  this 
structure  iaplies  that  the  security  kernel  is  interruptible, 
viz.,  is  not  a  critical  section;  however,  the  inner  traffic 
controller  itself  is  not  interruptible.  In  addition,  this 
layer  provides  all  the  aultiprocessing  interactions  between 
individual  physical  processors,  using  a  hardware  "preeapt" 
interrupt. 

ijeaor  7  flaaiast.  This  layer  aanages  the  aultiplexing  of  the 
physical  storage  resources,  viz.,  "disk"  and  "core".  This 
layer  also  aanages  the  segaent  descriptors  in  the  aeaory 
aanageaent  unit  (UNO)  iaage  for  each  process.  host  of  the 
functions  of  this  layer  are  executed  by  the  per-CPO  aeaory 


manager  processes,  with  synchronization  provided  by  inner 
traffic  controller  signal  and  wait  primitives.  The  single 
board  computers  have  per-processor,  local  memory;  there  is 
also  additional  global  memory  that  is  addressable  by  all 
processes.  The  memory  manager  insures  that  (only)  shared 
segments  are  in  global  memory. 

This  policy  can  require  some  transfers  between  local  and 
global  memory;  however,  the  low  transaction  rate  of  the  ar¬ 
chival  storage  system  is  not  demanding,  and  this  structure 
minimizes  bus  transfer  requirements  under  expected  operating 
conditions. 

Traffic  Controller.  The  variable  number  of  processes  (two 
per  host)  are  multiplexed  onto  virtual  processors  defined  by 
the  innar  traffic  controller.  Bach  process  has  an  affinity 
to  the  physical  processor  whose  local  memory  contains  a  por¬ 
tion  of  its  address  space  at  the  time  of  the  process  sche¬ 
duling  decision.  As  indicated  earlier,  the  traffic  cont¬ 
roller  layer  uses  Heed's  advance  and  await  mechanism  [9]  to 
provide  interprocess  communication. 

Segment  Bvqnt  Managers.  All  entries  into  the  kernel 
pass  through  the  segment/event  manager  layer.  The  explicit 
non-discretionary  security  checks  are  made  at  this  level  by 
comparing  the  access  class  labels  of  subjects  and  objects. 
This  layer  uses  a  per-process  known  segment  table  to  convert 
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process  local  naaes  (viz.,  segment  number)  for  objects  into 
system-wide  naaes.  Each  segment  has  associated  with  it  two 
eventcounts  and  a  sequencer;  thus*  segment  numbers  also 
serve  as  their  naaes.  The  segment  manager  provides  for  the 
creation  and  deletion  of  segments  and  their  entry  into  and 
removal  from  a  process  address  space. 

?ate  &2£2££.  A  process  invoices  a  security  kernel  function 
using  the  traditional  trap  mechanism.  The  Z8000  "system 
call"  instruction  causes  a  trap*  and  the  gate  keeper  is 
merely  the  trap  handler.  ill  parameters  and  return  values 
are  "passed  by  value"  in  CPU  registers;  this  simplifies  se¬ 
curity  validation.  The  gate  keeper  merely  calls  the  parti¬ 
cular  procedure  that  corresponds  to  the  requested  function. 
flifilSBI 2S£§§2£  XS3£2m£ 

One  important  aspect  of  this  research  has  been  the  actual 
implementation  and  testing  of  the  concepts  developed.  Trad¬ 
itionally  the  implementation  of  multiple  processor  struc¬ 
tures  has  been  an  expensive  undertaking.  Recently  the  de¬ 
velopment  of  sophisticated  microprocessors  that  feature 
multiple  operating  modes*  advanced  addressing*  support  of 
multiple  processor  configurations*  and  a  standard  bus  co¬ 
nfiguration  with  peripheral  support  have  all  made  the  imple¬ 
mentation  of  advanced  operating  systems  on  microprocessor 
devices  possible*  and  economically  feasible. 
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The  processors  of  SASS  all  share  the  saae  bos;  aach 
processor  is  a  coaaercial  single  board  computer  with  on¬ 
board  randoa  access  aesory.  These  processors  also  share  a 
global  aeaory,  and  certain  peripheral  devices.  This  co¬ 
nfiguration  is  illustrated  in  Figure  4. 

In  general,  security  kernel  bas«d  operating  systeas  find 
three  processor-supported  execution  domains  (operating 
states)  highly  desirable:  for  tfe#  kernel,  supervisor,  and 
applications.  This  is  true  of  the  operating  systea  faaily 
discussed  here.  Currently  there  are  no  single  chip  proces¬ 
sors  that  support  three  states.  This  is  not  a  significant 
problea  for  SASS,  since  it  is  the  hosts  rather  than  the  SASS 
systea  processors  that  execute  user  application  prograas. 
Under  these  circuastances  a  two  aode  (kernel  and  supervisor) 
machine  is  sufficient.  Such  architectures  are  currently 
available  as  microprocessors,  in  particular  the  Z8000. 

Accordingly,  we  are  iapleaenting  a  multiple  microproces¬ 
sor  systea  to  test  the  SASS  concept.  The  current  hardware 
in  use  is  the  AMD  4116  single  board  coaputer  £13]  in  a  stan¬ 
dard  Multibus  backplane.  This  configuration  has  a  signifi¬ 
cant  liaitation:  it  does  not  include  the  hardware  Memory 
Manager  Unit,  as  described  in  £2]. 


HOST  1 


•  •  • 

DATA  LINKS 


HOST  n 


SASS  BOUNDARY 


Figure  4:  Hultiprocessor  Configuration 
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Currently  we  simulate  in  software  the  aeaory  aanageaent 
unit,  so  the  Icernel  is  not  protected  froa  the  supervisor  as 
the  original  design  specified.  Hardware  protection  in  the 
fora  of  addressing  liaitations  is  available,  and  has  been 
used  in  soae  of  the  experiaents  to  assure  the  integrity  of 
the  kernel.  In  this  configuration,  the  hardware  protects 
one  half  of  the  local  aeaory  froa  any  access  when  the  CPtJ  is 
operating  in  the  noraal  node.  Any  atteapt  to  access  aeaory 
which  is  thus  protected  generates  an  interrupt  and  the  fault 
detection  software  traps  the  access.  This  is  adequate  for 
current  tests,  but  a  complete  aeaory  aanageaent  systea  is 
clearly  aore  desirable.  Our  experiences  on  this  testbed  in 
terns  of  perforaance  and  software  developaent  are  discussed 
further  below. 

i as  ass  sarnm 

The  lessons  learned  to  this  point  fall  into  two  broad  ca¬ 
tegories:  prograaaing  (software  engineering)  experiences, 
and  perforaance  experiences.  He  will  discuss  both  of  these 
issues  below. 

The  nature  of  this  research  effort  has  been  highly  struc¬ 
tured,  eaphasizing  nodularity  at  every  opportunity.  The 
software  design  is  strictly  "top-down".  This  has  been  a 
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■atter  of  good  design  practice,  and  of  necessity.  Since  the 
■ajority  of  the  work  has  been  perforned  by  a  succession  of 
Raster's  degree  students  [14, 15,16,17,18, 19 ]  during  their 
brief  six  to  nine  eonths  of  research  each,  the  clear  defini¬ 
tion  of  software  noddies  has  been  key  to  the  success  of  the 
effort.  we  have  found  that  the  high  degree  of  nodularity 
has  allowed  the  students  to  work  on  the  project  with  a  nini- 
aun  of  "start-up"  tine,  and  a  aaxinua  of  productive  effort 
and  learning. 

The  actual  inpleaentation  is  proceeding  in  an  essentially 
botton  up  aanner,  with  test  harnesses  and  stubs  being  writ¬ 
ten  as  necessary  for  testing.  The  SASS  nodules  were  speci¬ 
fied  in  a  pseudo-language  resenbling  current  higher  level 
languages.  The  SASS  nodules  as  inpleaented  were  coded  in 
PLZ-ASB  [20],  the  Z8000  structured  assenbly  language.  We 
found  that  the  pseudo-code  specifications  of  nodules  were 
adequate,  and  that  the  translation  fron  this  code  to  the 
structured  assenbly  language  was  straightforward. 

The  structured  assenbly  language  of  the  Zilog  Z8QQ0  sup¬ 
ported  aany  of  the  constructs  usually  thought  to  be  unique 
to  higher  level  languages,  including  typed  record  struc¬ 
tures,  DO-loops,  IP-THEH-ELSE,  and  CASE.  In  fact,  our  pro- 
graaaers  think  of  this  assenbly  language  as  a  higher  level 
language.  Approxinately  40  percent  of  the  statenents  writ- 


ten  in  SASS  are  equivalent  to  statements  in  modern  program¬ 
ming  languages. 


Despite  the  qualities  of  the  structured  assembler  it  was 
selected  by  default,  tfhen  the  decision  was  made,  the  proto¬ 
type  hardware  boards  were  just  becoming  available.  There 
was  virtually  no  software  support  available.  In  particular, 
no  higher  level  language  was  available.  The  software  envi¬ 
ronment  was  (by  modern  standards)  very  primitive,  with  no 
tools  for  operating  system  development  available.  Neverthe¬ 
less,  the  progression  from  microprocessor  development  system 
to  commercial  single  board  computer  system  has  been  surpris¬ 
ingly  smooth  (an  opinion  that  some  students  might  dispute) . 
The  software  development  environment  has  grown  slowly,  ret, 
this  has  not  proved  to  be  a  handicap. 


-  xxi  - 


ii— 


Eetf2I14a£g  ISSats 

Id  the  progranning  for  the  SASS,  we  have  generally  treat¬ 
ed  perforaance  as  a  secondary  issue,  in  deference  to  aore 
basic  concerns  such  as  security  and  nodularity.  However,  we 
have  addressed  perforaance  on  a  design  level  where  perfor¬ 
aance  is  strongly  related  to  ar  litectural  choices. 

Obviously,  one  basic  design  choice  is  the  use  of  aulti- 
processing  as  a  way  to  increase  processing  capacity.  Howev¬ 
er,  bus  contention  is  a  najor  perforaance  concern  in  the 
aultiprocessor  configurations,  since  all  processors  share  a 
single  Hultibus.  If,  for  exaaple,  all  code  and  data  were 
located  in  global  aeaory,  then  even  two  or  three  processors 
would  saturate  the  bus.  However,  in  reality  only  shared, 
writable  segaents  need  be  in  global  aeaory.  3ur  use  of  a 
purely  virtual,  segaented  aeaory  peraits  the  kernel  to  iet- 
eraine  exactly  which  are  the  shared,  writable  segaents.  As 
noted  before,  the  aeaory  aanager  layer  totally  controls  the 
allocation  to  global  aeaory,  and  thus  aarkedly  controls  bus 
contention. 

In  the  current  SASS  iapleaentation  we  use  the  "Normal" 
and  NSysteaN  nodes  of  the  Z8000  hardware,  with  the  systen 
aode  dedicated  to  the  security  kernel.  The  doaain  changes 
autoaatically  generate  a  switch  of  the  stack  within  the 
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hardware.  This  is  particularly  important  to  the  efficiency 
with  which  we  can  switch  doaains  while  aaintaining  the  in¬ 
tegrity  of  the  kernel. 

In  S&SS  a  process  switch  is  achieved  by  switching  the 
stack.  SASS  saves  the  process  history  in  the  stack,  so  a 
switch  requires  only  the  stack  exchange.  Preeapt  hardware 
interrupts  can  initiate  scheduler  changes,  and  associated 
virtual  interrupts  to  the  virtual  processors.  This  sequence 
is  relatively  efficient  given  the  Zilog  architecture.  The 
process  switching  performance  question  is  aore  interesting 
in  the  context  of  processor  aultiplexing. 

The  aultiprograaaing  time  is  the  interval  froa  the  tiae 
the  inner  traffic  controller  signal  priaitive  is  invoked  in 
one  virtual  processor  until  there  is  a  return  froa  a  (pend¬ 
ing)  wait  invocation  in  a  different  virtual  processor.  This 
includes  both  process  switching  and  aessage  passing  opera¬ 
tions. 

For  interprocess  coaaunication,  the  read  and  ticket  calls 
(froa  the  noraal  aode)  include  a  system  call  though  the  gate 
keeper  to  the  kernel,  the  non-discretionary  security  checks, 
and  access  to  the  eventcount  or  sequencer  value;  however,  no 
process  switch  is  involved.  The  synchronization  tiae  in¬ 
cludes  the  interval  froa  the  invocation  of  the  systea  call 
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(in  normal  mode)  for  advance  in  one  process  until  the  return 
froa  a  (blocking)  await  invocation  in  a  different  process. 
This  includes  the  security  checks  and  scheduling  of  both  a 
virtual  and  a  physical  processor. 

&  set  of  aeasureaents  on  the  current  iapleaentation  are 
suaaarized  in  Table  1.  There  has  been  no  effort  to  "tune" 
the  system  to  improve  performance.  He  find  these  results 
within  our  range  of  expectations  for  a  single  chip  micropro¬ 
cessor. 


Sulti programming 

signal/wait  pair 

Synchronization 

advance/await  pair 

Bead  (Eventcount) 

Ticket  (Sequencer) 


Xiii  (Sil±i§e£oa4§) 
0.5 


2.3 


0.6 


0.6 


Table  1.  Performance  aeasureaents 
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A  Modern  operating  systea  featuring  kernel  based  securi¬ 
ty,  segaented  aeaory  and  aultiple  processors  bas  been  de¬ 
signed  and  is  being  iapleaented  using  aodern  Microproces¬ 
sors.  To  date  our  focus  on  Methodical  design  has  paid  off: 
the  iapleaentation  of  a  carefully  designed,  siaple  structure 
using  eleaentary  software  developaent  tools  has  proceeded 
well. 

The  initial  testbed  iapleaentation  is  running  and  prelia- 
inary  data  is  now  available  regarding  the  operating  perfor- 
aance  of  such  systeas  iapleaented  on  Microprocessors  of  ad¬ 
vanced  architectures.  Data  gathered  suggests  that  the 
security  kernel  is  indeed  an  attractive  structure  for  a  Mo¬ 
dern  operating  systea.  There  is  a  wide  range  of  applica¬ 
tions  where  sophisticated  operating  systeas  can  be  iaple¬ 
aented  upon  Microprocessors,  and  attractive  perforaance  can 
be  achieved,  particularly  through  the  use  of  aultiple  pro¬ 
cessors. 
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This  technical  report  contains  edited  segaent s  of  four  tas¬ 
ters'  theses: 

Ika  assiaa  and  Iielftm&aUaa  si  tka  ttai2£i  flaaia- 
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BESkizal  Storage  System  by  A.  R.  strickler 

which  describe  the  developaent  and  iapleaentation  of  the  Na¬ 
val  Postgraduate  school  secure  Archival  Storage  Systea 
(SASS) .  These  theses  are  based  upon  the  design  outlined  in 
the  Naval  Postgraduate  School  SECURE  ARCHIVAL  STORAGE  SYSTEM 
Part  I  -  Design  -  by  R.  R.  Schell  and  L.  A.  Cox  [ 17].  This 
design  is  updated  and  presented  in  detail. 

Soae  sections  of  each  thesis  have  been  excluded  in  order 
to  eliainate  repetition  and  bulk.  Siailarly,  the  prograa 
listings  in  this  report  represent  the  current  state  of  the 
project  and  do  not  pertain  to  any  one  thesis.  An  atteapt 
has  been  aade  to  footnote  soae  discrepancies  between  the 
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systea  described  by  these  theses  and  the  current  state. 
However,  there  aay  be  soae  details  described  herein  which  do 
not  correspond  to  the  current  SASS  systea.  Consequently, 
the  reader  is  advised  to  consult  the  individual  thesis  if 
aore  detail  on  a  particular  phase  of  the  developaent  is  re¬ 
quired.  A  prograa  description  docuaent,  providing  greater 
clarification  of  SASS  organization  and  listings,  is  also 
available. 
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Chapter  I 
BACKGROUND 

This  chapter  is  an  updated  excerpt  froa  Iapleaen- 

laiiaa  a£  aaaiaai  flaaaaaBaat.  £sa  a  ass  us  Atsiiial 

Storage  Svstei  by  J.  T.  Hells  £20]. 

O'Connell  and  Richardson  provided  the  design  for  a  faai- 
ly  of  secure,  distributed,  nulti-aicroprocessor  operating 
systeas  froa  which  the  subset,  SASS,  was  later  derived  [7]. 
In  their  work,  two  of  the  priaary  aotivations  were  to  pro* 
vide  a  systea  that  (1)  effectively  coordinated  the  process¬ 
ing  power  of  aicroprocessors  and  (2)  provided  inforaation 
security. 

The  basis  for  eaphasis  on  utilization  of  aicroprocessors 
is  not  purely  that  of  replacing  software  with  lore  powerful 
(and  faster)  hardware  (aicroprocessors)  but  is  also  an  eco- 
noaic  issue.  Software  developaent  and  coaputing  operations 
are  becoaing  aore  and  aore  expensive,  putting  further  pres¬ 
sure  on  systea  designers  to  increasingly  utilize  people 
solely  for  systea  functions  that  coaputers  cannot  perfora  in 
a  cost  effective  aanner.  Microcoaputers,  on  the  other  hand, 
are  becoaing  less  and  less  expensive  and  are,  therefore,  in¬ 
creasingly  being  used  for  aore  functions. 

The  need  for  inforaation  security  has  been  gradually  re¬ 
cognized  as  the  uses  of  coaputers  have  expanded.  As  security 


needs  for  specific  coaputer  systems  hare  been  recognized, 
attempts  hare  been  aade  to  modify  the  existing  systeas  to 
proride  the  desired  security.  The  results  hare  been  systeas 
that  could  not  be  certified  as  secure  and/or  which  hare 
failed  to  resist  penetration  efforts,  i.e.  systeas  which,  in 
effect,  did  not  proride  adequate  inforaation  security.  It 
has  becone  clear  that,  in  order  to  be  certifiably  secure,  a 
coaputer  systea  must  hare  security  designed  in  froa  first 
principles  [10,11].  Such  is  the  case  with  SASS.  Inforaation 
security  was  and  continues  to  be  a  chief  design  feature. 
Integral  to  the  design  goal  of  inforaation  security  were  two 
related  goals.  One  of  these  goals  was  to  proride  aultilev- 
el  controlled  access  to  a  consolidated  warehouse  of  data  for 
a  network  of  multiple  host  coaputers.  The  other  key  goal  was 
to  provide  for  controlled  sharing  among  the  computer  hosts. 

A  brief  background  of  prior  work  relative  to  SASS  fol¬ 
lows.  O'Connell  and  Richardson  originated  the  design  of  a 
secure  faaily  of  operating  systeas.  Their  design  provided 
two  basic  parts  for  their  systea  —  the  supervisor  (to  pro¬ 
vide  operating  systea  services)  and  the  kernel  (to  provide 
for  physical  resource  management) .  The  design  of  the  SASS 
supervisor  was  coapleted  by  Parks  [9].  ho  implementation  or 
further  design  effort  on  the  supervior  has  followed,  to 
date.  The  initial  design  of  the  kernel  was  coapleted  by 
Coleaan  [2].  That  design  described  the  kernel  in  terns  of 


seven  nodules 


1.  Sate  Keeper  nodule  —  provided  for  ring-crossing  ae- 
cfaanisa  and  thus  isolation  of  the  kernel. 

2.  Segaent  Manager  Module  —  provided  for  aanageaent  of 
segaented  virtual  aeaory. 

3.  Traffic  Controller  Module  —  aultiplexed  processes 
onto  virtual  processors  and  supports  the  inter-  pro¬ 
cess  coaaunication  priaitives  Block  and  Makeup. 

4.  Mon-Discretionary  Security  Module  —  aediated  non- 
discretionary  security  access  atteapts. 

5.  Inner  Traffic  Controller  Module  —  aultiplexed  virtu¬ 
al  processors  onto  real  processors  and  provided  the 
Kernel  synchronization  priaitives  Signal  and  Hait. 

6.  Meaory  Manager  Module  —  aanaged  aain  aeaory  and  sec¬ 
ondary  storage. 

7.  Input-Output  Manager  --  aanaged  the  aoving  of  infor- 
aation  to  external  devices  outside  the  boundaries  of 
the  SASS. 

Refineaent  of  the  kernel  design  and  partial  iapleaentation 
was  coapleted  by  Gary  and  Moore  [5]  in  conjunction  with 
Reitz  £12].  The  resultant  description  of  the  kernel  as  a  re¬ 
sult  of  their  work  was: 

1.  Gate  Keeper  Module 

2.  Segaent  Manager  Module 

3.  Event  Manager  Module  —  worked  with  the  Traffic  Cont¬ 
roller  to  aanage  the  event  data  associated  with  the 
IPC  aechanisa  of  eventcounts  and  sequencers. 

4.  Mon-Discretionary  Security  Module 

5.  Traffic  Controller  Module  —  replaced  Block  and  Make¬ 
up  with  Advance  and  Await  (to  iapleaent  Supervisor 
IPC  aechanisa  of  eventcounts  and  sequencers). 

6.  Meaory  Manager  Module 

7.  Inner  Traffic  Controller  Module 
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Beitz  implemented  the  Traffic  Controller  nodule  and  Inner 
Traffic  Controller  nodule.  Gary  and  Moore  completed  a  de¬ 
tailed  design  of  the  Meeory  Manager*  originated  the  Heeory 
Manager  code  (written  predominantly  in  PLZ/SYS)*  selected  a 
thread  of  the  code*  hand  compiled  it  into  PLZ/1SM  and  ran  it 
on  the  ZSOOO  developmental  module.  Hells  provided  the  im¬ 
plementation  of  the  Segment  Manager  and  Mon-Discretionary 
Security  Modules  as  veil  as  partial  implementation  of  Dis¬ 
tributed  Memory  Manager  functions.  Strickler  refined  and 
implemented  the  process  management  functions  for  the  SiSS 
(written  in  PLZ/ASM)  . 
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Chapter  II 

BiSIC  COHCEPTS/DBPIIXZIOVS 


This  chapter  is  an  excerpt  froe  lipj^aentation  of 

££ssass  fliaaaataai  £21  a  s&suta  htakii al  sxataaa 

Svstea  by  A.  B.  Strickler  [19].  Minor  changes 
have  been  aade  for  integration  into  report. 

This  section  provides  an  overview  of  several  concepts 
essential  to  the  SASS  design.  Headers  faailiar  with  S ASS  or 
with  secure  operating  systea  principles  nay  wish  to  skip  to 
the  next  section. 

a.  msBss 

The  notion  of  a  process  has  been  viewed  in  aany  ways  in 
computer  science  literature.  Organick  [8]  defines  a  process 
as  a  set  of  related  procedures  and  data  undergoing  execution 
and  Manipulation,  respectively,  by  one  of  possibly  several 
processors  of  a  coaputer.  Madnick  and  Donovan  £6]  view  a 
process  as  the  locus  of  points  of  a  processor  executing  a 
collection  of  prograns.  Beed  [10]  describes  a  process  as 
the  sequence  of  actions  taken  by  soae  processor.  In  other 
words,  it  is  the  past,  present,  and  future  "history"  of  the 
states  of  the  processor.  In  the  SASS  design,  a  process  is 
viewed  as  a  logical  entity  entirely  characterized  by  an  ad¬ 
dress  space  and  an  execution  point.  A  process*  address 
space  consists  of  the  set  of  all  aeaory  locations  accessible 

-  6  - 

) 

; 

i 


by  the  process  daring  its  execution.  This  say  be  viewed  as 
a  set  of  procedures  and  data  related  to  the  process.  The 
execution  point  is  defined  by  the  state  of  the  processor  at 
any  given  instant  of  process  execution. 

As  a  Logical  entity,  a  process  say  have  logical  attri- 
butes  associated  with  it,  such  as  a  security  access  class,  a 
unique  identifier,  and  an  execution  state.  This  notion  of 
logical  attributes  should  not  be  confused  with  the  sore  typ¬ 
ical  notion  of  physical  attributes,  such  as  location  in  ne- 
nory,  page  size,  etc.  In  SASS,  a  process  is  given  a  securi¬ 
ty  access  class,  at  the  tine  of  its  creation,  to  specify 
what  authorization  it  possesses  in  terns  of  infornation  ac¬ 
cess  (to  be  discussed  in  the  next  section) .  It  is  also  giv¬ 
en  a  unique  identifier  that  provides  for  its  identification 
by  the  systen  and  is  utilized  for  interaction  anong  process¬ 
es.  &  process  nay  exist  in  one  of  three  execution  states: 
1)  running,  2)  ready,  and  3)  blocked.  In  order  to  execute, 
a  process  aust  be  sapped  onto  (bound  to)  a  physical  proces¬ 
sor  in  the  systea.  Such  a  process  is  said  to  be  in  the 
"running**  state.  A  process  that  is  not  napped  onto  a  physi¬ 
cal  processor,  but  is  otherwise  ready  to  execute,  is  in  the 
"ready"  state.  A  process  in  the  "blocked"  state  is  waiting 
for  soae  event  to  occur  in  the  systen  and  cannot  continue 
execution  until  the  event  occurs.  At  that  tine,  the  process 
is  placed  into  the  ready  state. 


B.  HC2BB AII2S  §££2£UX 

There  is  an  ever  increasing  deeand  for  coeputer  systeas 
that  can  provide  controlled  access  to  the  data  it  stores. 
In  this  thesis,  "inforaation  security"  is  defined  as  the 
process  of  controlling  access  to  inforaation  based  upon 
proper  authorization.  The  critical  need  for  inforaation  se¬ 
curity  should  be  clear.  Banks  and  other  coaaercial  enter¬ 
prises  risk  the  theft  or  loss  of  funds.  Insurance  and  cre¬ 
dit  coapanies  are  bound  by  law  to  protect  the  private  or 
otherwise  personal  inforaation  they  aaintain  on  their  cus- 
toaers.  Universities  and  scientific  institutions  aust  pre¬ 
vent  the  unauthorized  use  of  their  often  over-burdened  sys- 
teas.  The  Departaent  of  Defense  and  other  governaent 
agencies  aust  face  the  very  real  possibility  that  classified 
inforaation  is  being  coaproaised  or  that  weapon  systeas  are 
being  tanpered  with.  In  fact,  security  related  probleas  can 
be  found  at  virtually  every  level  of  coaputer  usage. 

The  security  of  coaputer  systeas  processing  sensitive 
inforaation  can  be  achieved  by  two  weans:  external  security 
controls  and  internal  security  controls.  In  the  first  case, 
security  is  achieved  by  encapsulating  the  coaputer  and  all 
its  trusted  users  within  a  single  security  periaeter  estab- 
lishe  by  physical  aeans  (e.g.,  araed  guards,  fences,  etc.) 
This  aeans  of  security  is  often  undesirable  due  to  its  added 
cost  of  iapleaentation,  the  inherent  risk  of  error-prone  aa- 
nual  procedures,  and  the  problea  of  trustworthy  but  error- 
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prone  users.  Also,  since  all  security  controls  are  external 
to  the  coaputer  system,  the  computer  is  incapable  of  secure¬ 
ly  handling  data  at  differing  security  levels  or  users  with 
differing  degrees  of  authorization.  This  restriction  great¬ 
ly  limits  the  utility  of  modern  computers.  Internal  securi¬ 
ty  controls  rely  upon  the  coaputer  system  to  internally  dis¬ 
tinguish  between  multiple  levels  of  information 
classification  and  user  authorization.  This  is  clearly  a 
more  desirable  and  flexible  approach  to  information  securi¬ 
ty.  This  does  not  mean,  however,  that  external  security  is 
not  needed.  The  optimal  approach  would  be  to  utilize  inter¬ 
nal  security  controls  to  maintain  information  security  and 
external  security  controls  to  provide  physical  protection  of 
our  system  against  sabotage,  theft,  or  destruction.  The 
primary  concern  of  this  thesis  is  information  security  and 
will  therefore  center  its  discussion  on  the  achievement  of 
information  security  through  implementation  of  the  security 
kernel  concept. 

One  might  argue  that  a  "totally  secure"  coaputer  system 
is  one  that  allows  no  access  to  its  classified  or  otherwise 
sensitive  information.  Such  a  system  would  not  be  of  much 
value  to  its  users.  Therefore,  when  we  say  that  a  system 
provides  information  security,  it  is  only  secure  with  res¬ 
pect  to  some  specific  external  security  policy  established 
by  laws,  directives,  or  regulations.  There  are  two  distinct 
aspects  of  security  policy:  non-discretionary  and  discre- 


t ionary.  Each  user  (subject)  of  the  systea  is  given  a  label 
denoting  what  classification  or  level  of  access  the  user  is 
authorized.  Likewise,  all  information  or  segments  (objects) 
within  the  systea  are  labelled  with  their  classification  or 
level  of  sensitivity.  The  non-discretionary  security  me¬ 
chanism  is  responsible  for  comparing  the  authorization  of  a 
subject  with  the  classification  of  an  object  and  determining 
what  access,  if  any,  should  be  granted.  The  DOD  security 
classification  systea  provides  an  example  of  the  non-discre- 
tionary  security  policy  and  is  the  policy  implemented  in 
SASS.  The  discretionary  security  policy  is  a  refinement  of 
the  non-discretionary  policy.  As  such,  it  adds  a  higher  de¬ 
gree  of  restriction  by  allowing  a  subject  to  specify  or  res¬ 
trict  who  may  have  access  to  his  riles.  It  must  be  empha¬ 
sized  that  the  discretionary  policy  is  contained  within  the 
non-discretionary  policy  and  in  no  way  undermines  or  substi¬ 
tutes  for  it.  This  prevents  a  subject  from  granting  access 
that  would  violate  the  non-discretionary  policy.  An  example 
of  discretionary  security  is  provided  by  the  DOD  "need  to 
know"  policy.  In  SASS,  the  discretionary  policy  is  imple¬ 
mented  within  the  supervisor  [9]  by  means  of  an  Access  Con¬ 
trol  List  (ACL) .  There  is  an  ACL  maintained  for  every  file 
in  the  system,  which  provides  a  list  of  all  users  authorized 
access  to  that  file.  Every  attempt  by  a  user  to  access  a 
file  is  first  checked  against  the  ACL  and  then  checked 
against  the  non-discretionary  security  policy.  The  "least" 


10 


r 


or  "lost  restrictive"  access  found  in  these  checks  is  then 
granted  to  the  user. 

The  relationship  between  the  labels  associated  with  the 
subject's  access  class  (sac)  and  the  object's  access  class 
(oac)  is  defined  by  a  lattice  aodel  of  secure  inforeation 
flow  [12]  as  follows  ("|"  denotes  "no  relationship"): 

1.  sac  »  oac,  read  and  write  access  pereitted 

2.  sac  >  oac,  read  access  peraitted 

3.  sac  <  oac,  write  access  peraitted 

4.  sac  |  oac,  no  access  peraitted 

In  order  to  understand  how  these  access  levels  are  deter¬ 
mined,  it  is  necessary  to  gain  an  awareness  of  and  consider¬ 
ation  for  several  basic  security  properties. 

»  *  * 

The  "Simple  Security  Property"  deals  with  "read"  access. 
It  states  that  a  subject  may  have  read  access  only  to  those 
object's  whose  classification  is  less  than  or  equal  to  the 
classification  of  the  subject.  This  prevents  a  subject  from 
reading  any  object  possessing  a  classification  higher  than 

>  i 

his  own. 

The  "Confinement  Property"  (also  known  as  ""-property") 
governs  "write"  access.  It  states  that  a  u^er  may  be  grant¬ 
ed  write  access  only  to  those  objects  whose  classification 
is  greater  than  or  equal  to  the  classification  of  the  sub- 

i 

ject.  This  prevents  a  user  from  writing  information  of  a 
higher  classification  (e.g..  Secret)  into  a  file  of  a  lower 
classification  (e.g.,  Onclassified) .  It  is  noted  that  while 
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this  property  allows  a  user  to  write  into  a  file  possessing 
a  classification  higher  than  his  own,  it  does  QOt  allow  hie 
access  to  any  of  the  data  in  that  file.  The  SASS  design 
does  not  allow  a  user  to  "write  up"  to  higher  classified 
files.  Therefore,  in  SASS,  "sac  <  oac"  denotes  "no  access 
permitted. " 

The  "Compatibility  Property"  deals  with  the  creation  of 
objects  in  a  hierarchical  structure.  In  SASS,  objects  (seg¬ 
ments)  are  hierarchically  organized  in  a  tree  structure. 
This  structure  consists  of  nodes  with  a  root  node  from  which 
the  tree  eminates.  The  Compatibility  Property  states  that 
the  classification  of  objects  must  be  non-decreasing  as  we 
move  down  the  hierarchical  structure.  This  prevents  a  pa¬ 
rent  node  from  creating  a  child  node  of  a  lower  classifica¬ 
tion. 

Several  prerequisites  must  be  net  in  order  to  insure 
that  the  security  kernel  design  provides  a  secure  environ¬ 
ment.  Pirstly,  every  attempt  to  access  data  must  invoke  the 
Kernel.  In  addition,  the  Kernel  must  be  isolated  and  tam¬ 
perproof.  Finally,  the  Kernel  design  must  be  verifiable. 
This  implies  that  the  mathematical  model,  upon  which  the 
Kernel  is  based,  must  be  proved  secure  and  that  the  Kernel 
is  shown  is  to  correctly  implement  this  model. 


c.  sfsasmixsi 


Segmentation  is  a  key  element  of  a  security  Kernel  based 
system.  A  segment  can  be  defined  as  a  logical  grouping  of 
information,  such  as  a  procedure,  file  or  data  area  [6]. 
Therefore,  we  can  redefine  a  process'  address  space  as  the 
collection  of  all  segments  addressable  by  that  process. 
Segmentation  is  the  technique  applied  to  effect  management 
of  those  segments  within  an  address  space.  In  a  segmented 
environment,  all  references  within  an  address  space  require 
two  components:  1)  a  segment  specifier  (number)  and  2)  the 
location  (offset)  within  the  segment. 

A  segment  may  have  several  logical  and  physical  attri¬ 
butes  associated  with  it.  The  logical  attributes  may  in¬ 
clude  the  segment's  classification,  size,  or  permissable  ac¬ 
cess  (read,  write,  or  execute).  These  logical  attributes 
allow  a  segment  to  nicely  fit  the  definition  of  an  object 
within  the  security  kernel  concept,  and  thus  provide  a  means 
for  the  enforcement  of  information  security.  A  segment's 
physical  attributes  include  the  current  location  of  the  seg¬ 
ment,  whether  or  not  the  segment  resides  in  main  memory  or 
secondary  storage,  and  where  the  segment's  attributes  are 
maintained  by  a  segment  descriptor.  The  segment  descriptors 
for  each  segment  in  a  process'  address  space  are  contained 
within  a  Descriptor  Segment  (viz.,  the  ttBO  Image  in  SASS)  to 
facilitate  the  memory  management  of  that  address  space. 
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Segmentation  supports  information  sharing  by  allowing  a 
single  segment  to  exist  in  the  address  spaces  of  multiple 
processes.  This  allows  us  to  forego  the  maintenance  of  mul- 
tiple  copies  of  the  same  segment  and  eliminates  the  possi¬ 
bility  of  conflicting  data.  Controlled  access  to  a  segment 
is  also  enforced,  since  each  process  can  have  different  at¬ 
tributes  (read/write)  specified  in  its  segment  descriptor. 
In  the  implementation  of  SASS,  any  segment  which  is  shared , 
but  has  "read  only"  access  by  every  process  sharing  it,  is 
placed  in  the  processor  local  memory  supporting  each  of 
these  processes  rather  than  in  the  global  memory.  This  im¬ 
plies  the  maintenance  of  multiple  copies  of  some  shared  seg¬ 
ments.  It  is  noted  that  the  problem  of  "conflicting  data" 
is  avoided  since  this  only  applies  to  read  only  segments. 
This  apparent  waste  of  memory  and  nonuse  of  existing  sharing 
facilities  is  justified  by  a  design  decision  to  provide  max¬ 
imum  reduction  of  bus  contention  among  processors  accessing 
global  memory.  This  reduction  in  bus  contention  is  consid¬ 
ered  to  be  of  sore  importance  than  the  saving  of  memory 
space  provided  by  single  copy  sharing  of  read  only  segments. 
This  decision  is  also  well  supported  by  the  occurrence  of 
decreasing  memory  costs,  which  we  have  experienced  in  terms 
of  high  speed  bus  costs. 


d.  MQMCXIQ1  22A4I22 


The  requirement  for  isolating  the  Kernel  froa  the  re- 
aainder  of  the  systea  is  achieved  by  dividing  the  address 
space  of  each  process  into  a  set  of  hierarchical  doaains  or 
protection  rings  [18].  O'Connell  and  Bichardson  [7]  defined 
three  doaains  in  the  faaily  of  secure  operating  systeas: 
the  user,  the  supervisor,  and  the  Kernel.  Only  two  doaains 
are  actually  necessary  in  the  SASS  design  since  it  does  not 
provide  extended  user  applications.  The  Kernel  resides  in 
the  inner  or  aost  privileged  doaain  and  has  access  to  all 
segaents  in  an  address  space.  Systea  wide  data  bases  are 
also  aaintained  within  the  Kernel  domain  to  insure  their  ac¬ 
cessibility  is  only  through  the  Kernel.  The  Supervisor  ex¬ 
ists  in  the  outer  or  least  privileged  doaain  where  its  ac¬ 
cess  to  data  or  segaents  within  an  address  space  is 
restricted. 

While  protection  doaains  nay  be  created  through  either 
hardware  or  software  aechanisas,  a  hardware  iapleaentation 
provides  auch  greater  efficiency.  Current  microprocessor 
technology  only  provides  for  the  iapleaentation  of  two  do¬ 
aains.  This  two  doaain  restriction  does  not  support  O'Con¬ 
nell  and  Bichardson* s  complete  faaily  design,  but  it  is  suf¬ 
ficient  to  allow  hardware  iapleaentation  of  the  ring 
structure  required  by  the  SASS  subset. 
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Dijkstra  [4  ]  has  shown  that  the  notion  of  abstraction 
can  be  used  to  reduce  the  complexity  of  a  problea  by  apply¬ 
ing  a  general  solution  to  a  number  of  specific  cases.  & 
structure  of  increasing  levels  of  abstraction  provides  a 
powerful  tool  for  the  design  of  complex  systems  and  general¬ 
ly  leads  to  a  better  design  with  greater  clarity  and  fewer 
errors. 

Each  level  of  abstraction  creates  a  virtual  hierarchical 
machine  [6]  which  provides  a  set  of  Mextended  instructions" 
to  the  system.  4  virtual  machine  cannot  make  calls  to 
another  virtual  machine  at  a  higher  level  of  abstraction  and 
in  fact  is  unaware  of  its  existence.  This  implies  that  a 
level  of  abstraction  is  independent  of  any  higher  levels. 
This  independence  provides  for  a  loop-free  design.  addi¬ 
tionally*  a  higher  level  may  only  make  use  of  the  resources 
of  a  lower  level  by  applying  the  extended  instruction  set  of 
the  lover  level  virtual  machine.  Therefore*  once  a  level  of 
abstraction  is  created*  any  higher  level  is  only  interested 
in  the  extended  instruction  set  it  provides  and  is  not  con¬ 
cerned  with  the  details  of  its  implementation.  In  S4SS* 
once  a  level  of  abstraction  is  created  for  the  physical  re¬ 
sources  of  the  system*  these  resources  become  "virtualized" 
making  the  higher  levels  of  the  design  independent  of  the 
physical  configuration  of  the  system. 
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S  ECO  SB  ABCHZYAL  STOBAGS  SYSTEM  DESIGI 


This  section  is  an  excerpwufros  I  ■Pleneatati.oQ  o£  Process 

Baaaaeasas.  far  a  Sasais  LlsMazL  Slacaaa  iistaa  by  a.  a. 

Strickler  [  19  ].  Minor  chang esIUiave  been  aade  for  integra- 
tion  into  this  report. 


Chapter  III 
BASIC  SASS  OYEBVIBB 

The  purpose  of  the  Secure  Archival  Storage  System  is  to 
provide  a  secure  "data  warehouse"  or  information  pool  which 
can  be  accessed  and  shared  by  a  variable  set  of  host  compu- 
ter  systems  possessing  differing  security  classifications. 
The  primary  goals  of  the  SASS  design  are  to  provide  informa¬ 
tion  security  and  controlled  sharing  of  data  among  system 
users. 

Figure  5  provides  an  example  of  a  possible  SASS  usage. 
The  system  is  used  exclusively  for  managing  an  archival  sto¬ 
rage  system  and  does  not  provide  any  programming  services  to 
its  users.  Thus  the  users  of  the  SASS  may  only  create, 
store,  retrieve,  or  modify  files  within  the  SASS.  The  host 
computers  are  hardwired  to  the  system  via  the  I/O  ports  of 
the  Z8001  with  each  connection  having  a  fixed  security  clas¬ 
sification.  Bach  host  must  have  a  separate  connection  for 
each  security  level  it  wishes  to  work  on  (It  is  important  to 
note  that  Figure  5  only  represents  the  logical  interfacing 
of  the  system.  Specifically,  the  actual  connection  with  the 
host  system  must  be  interfaced  with  the  Kernel  as  the  I/O 
instructions  for  the  port  are  privileged) .  In  our  example, 
host  *1  can  create  and  modify  only  Top  Secret  files,  but  it 
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can  read  files  which  are  Top  Secret,  Secret,  Confidential, 
or  Unclassified.  Likewise,  Host  #2  can  create  or  modify 
secret  files,  using  its  secret  connection  or  confidential 
files,  using  its  confidential  connection.  Host  *2  cannot 
create  or  modify  Top  Secret  or  Unclassified  files. 

In  order  to  provide  information  security  and  controlled 
sharing  of  files,  the  SASS  operates  in  two  doeains:  (1)  the 
Supervisor  doaain  and  (2)  the  Kernel  doaain.  The  SASS  ac- 
hieves  this  desired  environaent  through  a  distributed  oper- 
ating  systea  design  which  consists  of  two  primary  aodules: 
the  Supervisor  and  the  Security  Kernel.  Bach  host  systea 
connected  to  the  SASS  has  associated  with  it  two  processes 
within  the  SASS  which  perfora  the  data  transfer  and  file 
aanageaent  on  behalf  of  that  host.  The  host  computer  commu¬ 
nicates  directly  with  its  own  I/O  process  and  Pile  Hanager 
process  within  the  SASS. 

He  can  use  our  notion  of  abstraction  to  present  a  systea 
overview  of  the  SASS.  The  SASS  consists  of  four  primary 
levels  of  abstraction: 

Level  3-The  Host  Computer  Systems 
Level  2-The  Supervisor 
Level  1-The  Security  Kernel 
Level  O-The  SASS  Hardware 

A  pictorial  representation  of  this  abstract  system  overview 
is  presented  in  Figure  6.  This  representation  is  limited  to 
a  dual  host  systea  for  clarity  and  space  restrictions.  Note 
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that  the  Sate  Keeper  aodale  is  in  actuality  the  logical 
boundary  between  levels  one  and  two  and  as  such  will  be  de¬ 
scribed  separately. 

Level  3,  the  host  computer  systeas*  of  SASS  has  already 
been  addressed.  It  should  be  noted  that  the  SASS  design 
■akes  no  assuaptions  about  the  host  computer  systeas.  There¬ 
fore  each  host  aay  be  of  a  different  type  or  size  (i.e.-  ai- 
crof  aini,  or  aazi-coaputer  systea) .  Furtheraore,  the  ne¬ 
cessary  physical  security  of  the  host  systeas  and  their 
respective  data  links  with  the  SASS  is  assuaed. 
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Figure  6:  Systea  Overview  (Dual  Host) 


Chapter  IT 
SQPBBTISOB 

Level  2  of  the  SASS  system  is  coaposed  of  the  Supervisor 
domain.  As  already  stated,  the  SASS  consists  of  two  do¬ 
mains.  The  actual  implementation  of  these  domains  was 
greatly  simplified  since  the  Z8001  microprocessor  provides 
two  modes  of  execution.  l'he  system  mode,  with  which  the 
Kernel  was  implemented,  provides  access  to  all  machine  in¬ 
structions  and  all  segments  within  the  system.  The  normal 
mode,  with  which  the  Supervisor  was  implemented,  only  pro¬ 
vides  access  to  a  limited  subset  of  machine  instructions  and 
segments  within  the  system.  Therefore,  the  Supervisor  oper¬ 
ates  in  an  outer  or  less  privileged  domain  than  the  Kernel. 

The  purpose  of  the  Supervisor  is  to  manage  the  data  link 
between  the  host  computer  systems  and  the  SASS  by  means  of 
Input/Output  control,  and  to  create  and  manage  the  file 
hierarchy  of  each  host  within  the  SASS.  These  functions  are 
accomplished  via  an  Input/Output  (I/O)  process  and  a  Pile 
Manager  (PM)  process  within  the  Supervisor.  A  separate  FM 
and  I/O  process  are  created  and  dedicated  to  each  host  at 
the  tine  of  system  initialization. 


23 


I 


*•  fits  S&liSSS  gSQgSSS 

The  PH  process  directs  the  interaction  between  the  host 
cosputer  systeas  and  the  SASS.  It  interprets  all  cossands 
received  froa  the  Host  coaputer  and  perforas  the  necessary 
action  upon  then  through  appropriate  calls  to  the  Kernel. 
The  prisary  functions  of  the  FH  process  are  the  sanagesent 
of  the  Host's  virtual  file  systea  and  the  enforceaent  of  the 
discretionary  security  policy. 

The  virtual  file  systea  of  the  Host  is  viewed  as  a  hier¬ 
archy  of  files  which  are  iapleaented  in  a  tree  structure. 
The  five  basic  actions  which  nay  be  initiated  upon  a  file  at 
this  level  are:  1)  to  create  a  file,  2)  to  delete  a  file,  3) 
to  read  a  file,  4)  to  store  a  file,  and  5)  to  modify  a  file. 
The  PH  process  utilizes  a  PH  Known  segaent  Table  (FA_KST)  as 
the  priaary  database  to  aid  in  this  aanageaent. 

The  PH  process  aaintains  an  Access  Control  List  (ACL) 
through  which  it  enforces  the  discretionary  security  in 
SASS.  The  PH  process  initializes  an  ACL  for  every  file  in 
its  Host's  file  systea.  The  ACL  is  aerely  a  list  of  all  us¬ 
ers  that  are  authorized  to  access  that  file.  The  ACL  is 
checked  upon  every  atteapt  to  access  a  file  to  deteraine  its 
authorization.  The  user  (host  computer)  directs  the  PH  pro¬ 
cess  as  to  what  entries  or  deletions  should  be  aade  in  the 
ACL,  and  as  such,  specifies  who  he  wishes  to  have  access  to 
his  file.  As  noted  earlier,  discretionary  security  is  a  re- 
fineaent  to  the  Non-Discretionary  Security  Policy  and  there- 
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fore  can  only  be  utilized  to  add  further  access  restrictions 
to  those  provided  by  the  Hon-Discretionary  Security.  This 
prevents  a  user  from  granting  access  to  a  file  to  soeeone 
who  otherwise  would  not  be  authorized  access. 

B.  IKE9XlSmJ2£  £12 

The  1/3  process  is  responsible  for  aanaging  the  input 
and  output  of  all  data  between  the  host  computer  systems  and 
the  5 ASS .  The  X/0  process  is  subservient  to  the  Fa  process 
and  receives  all  of  its  coaaands  froa  it.  Data  is  transfer¬ 
red  between  the  SASS  and  Host  Coaputer  systeas  in  fixed  size 
"packets".  These  packets  are  broken  up  into  three  basic 
types:  1)  a  synchronization  packet,  2)  a  coaaand  packet,  and 
3)  a  data  packet.  In  order  to  insure  reliable  transaission 
and  receipt  of  packets  between  the  Host  coaputer  and  the 
SASS,  there  aust  exist  a  protocol  between  them.  Parks  [9] 
provides  a  aore  detailed  description  of  these  packets,  and  a 
possible  multi-packet  protocol. 
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Chapter  T 
GATE  KEEPER 

The  priaary  objective  of  the  gate  Keeper  is  to  isolate 
the  Kernel  and  aake  it  taaperproof.  This  goal  is  accoa- 
plished  by  reason  of  a  software  ring  crossing  aechanisa  pro** 
vided  by  the  gate  Keeper.  In  teras  of  SASS,  this  notion  of 
"ring-crossing1*  is  aerely  the  transition  froa  the  Supervisor 
doaain  to  the  Kernel  doaain.  As  noted  earlier ,  the  gate 
Keeper  establishes  the  logical  boundary  between  the  Supervi¬ 
sor  and  the  Kernel,  and  as  a  aatter  of  course,  it  provides  a 
single  software  entry  point  (enforced  by  hardware)  into  the 
Kernel.  Therefore,  any  call  to  the  Kernel  east  first  pass 
through  the  gate  Keeper. 

The  gate  Keeper  acts  as  a  trap  handler.  Once  it  is  in¬ 
voked  by  a  user  (Supervisor)  process,  the  hardware  preeapt 
interrupts  are  aasked,  and  the  user  process'  registers  and 
stack  pointer  are  saved  (within  the  Kernel  doaain) .  It  then 
takes  the  arguaent  list  provided  by  the  caller  and  validates 
these  passed  paraaeters  to  insure  their  correctness.  To  aid 
in  the  validation  of  these  paraaeters,  the  gate  keeper  uti¬ 
lizes  the  Paraaeter  Table  as  a  database.  The  Paraaeter  ta¬ 
ble  contains  all  of  the  peraitted  functions  provided  by  the 
Kernel.  These  relate  directly  to  the  extended  instruction 
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set  (viz..  Supervisor  calls)  provided  by  the  Kernel  (these 
extended  instructions  will  be  described  in  the  next  sec¬ 
tion)  .  If  an  invalid  call  is  encountered  by  the  gate  keep¬ 
er,  'an  error  code  is  returned,  and  the  Kernel  is  not  in¬ 
voked.  If  a  valid  call  is  encountered  by  the  gate  keeper, 
the  arguments  and  control  are  passed  to  the  appropriate  Ker¬ 
nel  aodule. 

Once  the  Kernel  has  completed  its  action  on  the  user  re¬ 
quest,  it  passes  the  necessary  parameters  and  control  back 
to  the  gate  keeper.  At  this  point,  the  gate  keeper  deter- 
aines  if  any  software  virtual  preeapt  interrupts  have  occur¬ 
red.  If  they  have,  then  the  virtual  preempt  handler  is  in¬ 
voked  vice  the  Kernel  being  exited  (virtual  interrupt 
structure  is  discussed  by  strickler  [19].  correspondingly, 
if  a  software  virtual  preeapt  has  not  occurred,  then  the  re¬ 
turn  arguments  are  passed  to  the  user  process.  The  user 
process'  registers  and  stack  pointer  (viz.,  its  execution 
point)  are  restored  and  control  returned  to  the  Supervisor 
domain.  A  detailed  description  of  the  Gate  Keeper  interface 
and  implementation  is  provided  by  Strickler  [ 19]. 
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Chapter  VI 
DISTRIBUTED  KERNEL 

Level  1  of  our  abstract  view  of  SASS  consists  of  two 
components:  the  distributed  Kernel  and  the  non-distributed 
Kernel.  These  two  elements  coaprise  the  Security  Kernel  of 
the  SASS.  The  Security  Kernel  has  two  priaary  objectives: 
1)  the  aanageeent  of  the  systea's  hardware  resources,  and  2) 
the  enforcement  of  the  non-discretionary  security  policy. 
It  executes  in  the  aost  privileged  domain  (viz.,  the  systea 
aode  of  the  Z8001)  and  has  access  to  all  machine  instruc¬ 
tions.  The  following  section  will  provide  a  brief  descrip¬ 
tion  of  the  distributed  Kernel,  its  components,  and  the  ex¬ 
tended  instruction  set  it  provides.  A  discussion  of  the 
non-distributed  Kernel  will  be  given  in  the  next  section. 

The  distributed  Kernel  consists  of  those  Kernel  modules 
whose  segments  are  contained  (distributed)  in  the  address 
space  of  every  user  (Supervisor)  process.  Thus,  in  effect, 
the  distributed  Kernel  is  shared  by  all  user  processes  in 
the  SASS.  The  distributed  Kernel  is  composed  of  the  Segment 
Manager,  the  Event  Manager,  the  Mon-Discretionary  Security 
Module,  the  Traffic  Controller,  the  Inner  Traffic  Controll¬ 
er,  and  the  Distributed  Memory  Manager  Module.  The  Segment 
Manager  and  the  Event  Manager  are  the  only  "user  visible" 
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nodules  in  the  distributed  Kernel.  Tn  other  words,  the  sat 
o£  extended  instructions  available  to  us»>r  processes  invokes 
either  the  Segaent  Manager  or  the  Event  Manager. 

SSS5SI1 

The  objective  of  the  Segaent  Manager  is  the  aanageaent 
of  a  process'  segmented  virtual  storage.  The  Segaent  Manag¬ 
er  is  invoked  by  calls  froa  the  Supervisor  doaain  via  the 
gate  keeper.  Calls  to  the  Segaent  Manager  are  Bade  by  Beans 
of  six  extended  instructions  provided  by  the  segaent  aanag- 
er.  These  extended  instructions  (viz.,  entry  points)  are: 
1)  CREATE_SEGMENT ,  2)  DELETE_SE GHENT,  3)  MAKE_KNOMN,  4) 
TERMINATE,  5)  SM_SHAP_IN,  and  6)  SM_S«AP_OOT.  The  extended 
instructions  CHEATE.SEGMENT  and  DELEXE_SEGMENT  add  and  re- 
aove  segaents  froa  the  SASS.  MAKE.KNOHN  and  TERMINATE  add 
and  renove  segaents  froa  the  address  space  of  a  process. 
Finally,  SM_SW&P_IN  and  SH_S*AP_OOT  aove  segments  froa  sec¬ 
ondary  sto-age  to  main  storage  and  vice  versa. 

The  primary  database  utilized  by  the  Segaent  Manager  is 
the  Known  Segaent  Table  (KST) .  A  representation  of  the 
structure  of  the  KST  is  provided  in  Figure  7.  The  KST  is  a 
process  local  database  that  contains  an  entry  for  every  seg¬ 
aent  in  the  address  space  of  that  process.  The  KST  is  in¬ 
dexed  by  segment  number  with  each  record  of  the  KST  contain¬ 
ing  descriptive  inforaation  for  a  particular  segaent.  The 
KST  provides  a  sapping  mechanise  by  which  the  segaent  nuaber 
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of  a  particular  segment  can  be  converted  into  a  unique  han¬ 
dle  for  use  by  the  Memory  Manager.  The  Memory  Manager  will 
be  discussed  in  the  next  chapter. 
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Figure  7:  Known  Segaent  Table  (KST) 
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b.  SXSM1  SMAS5E 

The  purpose  of  the  Event  Manager  is  the  eanageaent  of 
event  data  which  is  associated  with  interprocess  coaaunica- 
tions  within  the  S&S5.  This  event  data  is  iapleaented  by 
aeans  of  eventcounts  (a  synchronization  priaitive  discussed 
by  Seed  [11]).  The  Event  Manager  is  invoked*  via  the  Sate 
Keeper*  by  user  processes  residing  in  the  Supervisor  doaain. 
There  are  two  eventcounts  associated  with  every  segaent  ex¬ 
isting  in  the  supervisor  doaain.  These  eventcounts  (viz.* 
Instance  1  and  Instance  2)  are  aaintained  in  a  database  re¬ 
siding  in  the  Neaory  Manager.  The  Event  Manager  provides 
its  aanageaent  functions  through  its  extended  instruction 
set  HEAD*  TICKET,  ADVANCE,  and  AMAIT,  and  in  conjunction 
with  the  extended  instructions  TC_AD¥AMCE  and  TC_AIAIT  pro¬ 
vided  by  the  Traffic  Controller  (to  be  discussed  next) . 
These  extended  instructions  are  based  on  the  aechanisa  of 
eventcounts  and  sequencers  [11].  The  Event  Manager  verifies 
the  access  peraission  of  every  interprocess  coaaunication 
request  through  the  Non-Oiscretionary  Security  Module.  The 
extended  instruction  BEAD  provides  the  current  value  of  the 
eventcount  requested  by  the  caller.  TICKET  provides  a  com¬ 
plete  tiae  ordering  of  possibly  concurrent  events  through 
the  aechanisa  of  sequencers.  The  Event  Manager  will  be  dis¬ 
cussed  in  aore  detail  by  Strickler  [ 19]. 


32 


c.  B2BrfiI5£fiSII2I4SI  BSCJZUXX  422211 

The  purpose  of  the  Mon-Discretionary  security  Module 

(NDS)  is  the  enforcement  of  the  non-discret ionary  security 
policy  of  the  SASS.  ihile  the  current  implementation  of 
SASS  represents  the  Department  of  Defense  security  policy# 
any  security  policy  which  may  be  represented  through  a  lat¬ 
tice  structure  [3]  nay  also  be  implemented.  The  NDS  is  in¬ 
voked  via  its  extended  instruction  set:  CLASS. EQ  and 

CLASS.SE.  The  NDS  is  passed  two  classifications  which  it 
compares  and  then  analyzes  their  relationship.  CLASS. EQ 
will  return  a  true  value  to  the  calling  procedure  only  if 
the  two  classifications  passed  were  equal.  The  CLASS.GE  in¬ 
struction  will  return  true  if  a  given  classification  is  ana¬ 
lyzed  to  be  either  greater  than  or  equal  to  another  given 
classification.  The  NDS  does  not  utilize  a  data  base  as  it 
works  only  with  the  parameters  it  is  passed. 

o.  ZBmiS  £211221112 

The  task  of  processor  scheduling  is  performed  by  the 
traffic  controller.  Saltzer  [14]  defines  traffic  controller 
as  the  processor  multiplexing  and  control  communication  sec¬ 
tion  of  an  operating  system.  The  current  SASS  design  uti¬ 
lizes  Beed*s  [10]  notion  of  a  two  level  traffic  controller# 
consisting  of:  1)  a  Traffic  Controller  (TC)  and  2)  an  Inner 
Traffic  Controller  (XTC). 
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The  priaary  function  of  the  Traffic  Controller  is  the 
scheduling  (binding)  of  user  processes  onto  virtual  proces¬ 
sors.  A  virtual  processor  (7P)  is  an  abstract  data  struc¬ 
ture  that  simulates  a  physical  processor  through  the  preser¬ 
vation  of  an  executing  process'  attributes  (viz.,  the 
execution  point  and  address  space),  Multiple  VP's  aay  exist 
for  every  physical  processor  in  the  systea.  Two  VP's  are 
peraanently  bound  to  Kernel  processes  (viz.,  Heaory  Manager 
and  Idle)  and  as  such  are  not  in  contention  for  process 
scheduling.  These  processes  and  their  corresponding  virtual 
processors  are  invisible  to  the  TC.  The  ceaaining  virtual 
processors  are  either  idle  or  are  teaporarily  bound  to  user 
processes  as  scheduled  by  the  TC.  The  database  utilized  by 
the  TC  in  process  scheduling  is  the  Active  Process  Table 
(APT) .  Pigure  8  provides  the  structure  of  the  APT. 

The  APT  is  a  systea-wide  Kernel  database  containing  an 
entry  for  every  user  process  in  the  systea.  Since  the  cur¬ 
rent  SASS  design  does  not  provide  for  dynaaic  process  crea¬ 
tion/deletion,  a  user  process  is  active  for  the  life  of  the 
systea.  Therefore,  the  size  of  the  APT  is  fixed  at  the  tiae 
of  systea  generation.  The  APT  is  logically  coaposed  of 
three  pacts:  1)  an  APT  header,  2)  the  aain  body  of  the  APT, 
and  3)  a  VP  table.  The  APT  header  includes:  1)  a  Lock  to 
provide  for  a  autual  exclusion  aechanisa,  2)  a  Sunning  List 
indexed  by  VP  ID  to  identify  the  current  process  running  on 
each  VP,  3)  a  Ready  List,  which  points  to  the  linked  list  of 
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processes  which  are  ready  for  scheduling,  and  4)  a  Blocked 
List,  which  points  to  the  linked  list  of  processes  which  are 
in  the  blocked  state  awaiting  the  occurrence  of  soae  event. 

A  design  decision  was  sade  to  incorporate  a  single  list 
of  blocked  processes  instead  of  the  sore  traditional  notion 
of  separate  lists  per  eventcount  because  of  its  sisplicity 
and  its  ease  of  iaplesentation.  This  decision  does  not  ap¬ 
preciably  affect  systea  perforaance  or  efficiency  as  the 
"blocked"  list  will  never  be  very  long.  The  VP  table  is  in¬ 
dexed  by  logical  CPU  nuaber  and  specifies  the  nuaber  of  VP's 
associated  with  the  logical  CPU  and  its  first  VP  in  the  Sun¬ 
ning  List.  The  logical  CPU  nuaber,  obtained  during  systea 
initialization,  provides  a  siaple  aeans  of  uniguely  identif¬ 
ying  each  physical  CPU  in  the  systea.  The  aain  body  of  the 
APT  contains  the  user  process  data  reguired  for  its  effi¬ 
cient  control  and  scheduling.  NEXT_AP  provides  the  linked 
list  threading  aechanisa  for  process  entries.  The  DBS  entry 
is  a  handle  identifying  the  process'  Descriptor  Segaent 
which  is  eaployed  in  process  switching  and  aeaory  nanage- 
aent.  The  ACCESS_CLASS  entry  provides  every  process  with  a 
security  label  that  is  utilized  by  the  Event  Banager  and  the 
Segaent  Banager  in  the  enforceaent  of  the  Non-Discretionary 
Security  Policy.  The  PRIORITY  and  STATE  entries  are  the 
priaary  data  used  by  the  Traffic  Controller  to  effect  pro¬ 
cess  scheduling.  AFFINITY  identifies  the  logical  CPU  which 
is  associated  with  the  process.  VP  ID  is  utilized  to  iden- 
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tify  the  virtual  processor  that  is  currently  bound  to  the 
process.  Finally,  the  BVENTCOUNT  entries  are  utilized  by 
the  TC  to  aanage  processes  which  are  blocked  and  awaiting 
the  occurrence  of  soee  event.  HANDLE  identifies  the  segaent 
associated  with  the  event,  INSTANCE  specifies  the  event,  and 
COUNT  deteraines  which  occurrence  of  the  event  is  needed. 

The  Traffic  Controller  deteraines  the  scheduling  order 
by  process  priority.  Every  process  is  assigned  a  priority 
at  the  time  of  its  creation.  Once  scheduled,  a  process  will 
run  on  its  VP  until  it  either  blocks  itself  or  it  is 
preeapted  by  a  higher  priority  process.  To  insure  that  the 
TC  will  always  have  a  process  available  for  scheduling, 
there  logically  exists  an  "idle"  process  for  every  VP  visi¬ 
ble  to  the  TC.  These  "idle"  processes  exist  at  the  lowest 
process  priority  and,  consequently,  are  scheduled  only  if 
there  exists  no  useful  work  to  be  performed. 

The  Traffic  Controller  is  invoked  by  the  occurrence  of  a 
virtual  preempt  interrupt  or  through  its  extended  instruc¬ 
tion  set:  ADVANCE,  AWAIT,  PBOCESS..CLASS,  and 
GET.DBBJIUMBBB.  ADVANCE  and  AHAIT  are  used  to  iapleaent  the 
IPC  mechanism  envoked  by  the  Supervisor.  PBOCESS_CLASS  and 
GET_DBR_NUHBEB  are  called  by  the  Segment  Manager  to  ascer¬ 
tain  the  security  label  and  DBB  handle,  respectively,  of  a 
naaed  process.  A  aore  detailed  discussion  of  the  TC  is  pro¬ 
vided  by  Strickler  [19]. 


37 


E.  IMBSB  liktllQ  SSBIBQttBB 

The  Inner  Traffic  Controller  is  the  second  part  of  our 

two-level  traffic  controller.  Basically,  the  ITC  performs 
two  functions.  It  aultiplexes  virtual  processors  onto  the 
actual  physical  processors,  and  it  provides  the  priaitives 
for  which  inter-VP  coaaunication  within  the  Kernel  is  imple- 
aented.  A  design  choice  was  aade  to  provide  each  physical 
processor  in  the  systea  with  a  saall  fixed  set  of  virtual 
processors.  Two  of  these  VP's  are  permanently  bound  to  the 
Kernel  processes.  The  Memory  Manager  is  bound  to  the  high¬ 
est  priority  VP.  Conversely,  the  Idle  Process  is  bound  to 
the  lowest  priority  VP  and,  as  a  result,  will  only  be  sche¬ 
duled  if  there  exists  no  useful  work  for  the  CPU  to  perfora. 
The  priaary  database  utilized  by  the  ITC  is  the  Virtual  Pro¬ 
cessor  Table  (VPT) .  Figure  9  illustrates  the  vpt. 

The  VPT  is  a  system  wide  Kernel  database  containing  en¬ 
tries  for  every  CPU  in  the  system.  The  VPT  is  logically 
composed  of  four  parts:  1)  a  header,  2)  a  VP  data  table,  3) 
a  message  table,  and  4)  an  external  VP  lis..  The  header  in¬ 
cludes  a  LOCK  (spin  lock)  that  provides  a  mutual  exclusion 
mechanism  for  table  access,  a  BUNKING  LIST  (indexed  by  logi¬ 
cal  CPU  #)  that  identifies  the  VP  currently  running  on  the 
corresponding  physical  CPU,  a  BEADT  LIST  (indexed  by  logical 
CPU  #)  which  points  to  the  linked  list  of  VP's  which  are  in 
the  "ready"  state  and  awaiting  scheduling  on  that  CPU,  and  a 
FREE  LIST  which  points  to  the  linked  list  of  unused  entries 
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Figure  9:  virtual  Processor  ratio  (VPT) 


in  the  aessage  table.  The  VP  data  table  contains  the  de¬ 
scriptive  data  required  by  the  1TC  to  effectively  aanage  the 
virtual  processors.  The  DBB  entry  points  within  the  MMO  la- 
age  to  the  descriptor  segaent  for  the  process  currently  run¬ 
ning  on  the  VP.  PRI  (Priority)  ,  STATE,  IDLE_FLAG ,  and 
PREEMPT  are  the  priaary  data  used  by  the  ITC  for  VP  schedul¬ 
ing.  PREEMPT  indicates  whether  or  not  a  virtual  preeapt  is 
pending  for  the  VP.  The  IDLE_P LAG  is  set  whenever  the  TC 
has  bound  an  "idle1*  process  to  the  VP.  Moraally,  a  VP  with 
the  IDLE_FLAG  set  will  not  be  scheduled  by  the  ITC  as  it  has 
no  useful  work  to  perfora.  In  fact,  such  a  VP  will  only  be 
scheduled  if  the  PREEMPT  flag  is  set.  This  scheduling  will 
allow  the  VP  to  be  given  (bound)  to  another  process. 
PHYSICAL  PROCESSOR  contains  an  entry  froa  the  Processor  Data 
Segaent  (PRDS)  that  identifies  the  physical  processor  that 
the  VP  is  executing  on.  EXT_VP_ID  is  the  identifier  by 
which  the  VP  is  known  by  the  Traffic  Controller.  A  design 
choice  was  aade  to  have  the  EXI_VP_ID  equate  to  an  offset 
into  the  External  VP  List.  The  External  VP  List  specifies 
the  actual  VP  ID  (viz.,  VPT  entry  nuaber)  for  each  external 
VP  identifier.  This  precluded  the  necessity  for  run  tiae 
calculation  of  offsets  for  the  EXT_VP_ID.  HEXT_READY_VP 
provides  the  threading  aechanisa  for  the  "Ready"  linked 
list,  and  MSG_LIST  points  to  the  first  entry  in  the  Message 
Table  containing  a  message  for  that  VP.  The  Message  Table 
provides  storage  for  the  aessages  generated  in  the  course  of 


Inter-Virtual  Processor  communications 


MSG  contains  the 


actual  coaaunication  being  passed,  while  SENDEE  identifies 
the  VP  which  initiated  the  coaaunication.  NEXT_MSG  provides 
a  threading  aechanisa  for  multiple  aessages  pending  for  a 
single  VP. 

The  ITC  is  invoiced  by  leans  of  its  extended  instruction 
set:  BAII,  SIGNAL,  SHAPJFDBB,  IDLE,  SET_PBEENPT,  and 
RUNNING_VP.  WAIT  and  SIGNAL  are  the  priaitives  employed  in 
implementing  the  Inter-*VP  coaaunication.  SHAP.VDBB,  IDLE, 
SETJ?REEMPT,  and  fiUNNING_VP  are  all  invoiced  by  the  Traffic 
Controller.  SHAP_VDBB  provides  the  aeans  by  which  a  user 
process  is  temporarily  bound  to  a  virtual  processor.  IDLE 
binds  the  "Idle”  process  to  a  VP  (the  implication  of  this 
instruction  will  be  discussed  later) .  SET_P BEEHPT  provides 
the  aeans  of  indicating  that  a  virtual  preempt  interrupt  is 
pending  on  a  VP  (specified  by  the  TC)  by  setting  the  PfiEEMPT 
flag  for  that  VP  in  the  VPT.  BUNNING..VP  provides  the  TC 
with  the  external  VP  ID  of  the  virtual  processor  currently 
running  on  the  physical  processor. 

f-  eisiaxemc  asfl&u  auassb 

The  Distributed  Heaory  Manager  provides  an  interface 
structure  between  the  Segaent  Manager  and  the  Meaory  Manager 
Process.  This  interfacing  is  necessitated  by  the  fact  that 
the  Memory  Manager  Process  does  not  reside  in  the  Distribut¬ 
ed  Kernel  and  consequently  is  not  included  in  the  user  pro- 
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cess*  address  space.  The  primary  functions  perforaed  in 
this  nodule  are  the  establishment  of  Inter-VP  Coaaunication 
between  the  VP  bound  to  its  user  process  and  the  VP  perma¬ 
nently  bound  to  the  Memory  Manager  Process,  the  aanipulation 
of  event  data,  and  the  dynanic  allocation  of  available  memo¬ 
ry.  The  Distributed  Meaory  Manager  Module  is  invoked  by  the 
Segaent  Manager  through  its  extended  instruction  set: 
MM_CREATE_ENTHr,  MM_DELETE_EHTRI ,  MM_ACTIVATE, 
NN_DE ACTIVATE,  MM_SHAP_IN,  and  MM_SHAP_OUT.  These  extended 
instructions  are  utilized  on  a  one  to  one  basis  by  the  ex¬ 
tended  instruction  set  of  the  Segaent  Manager  (e. g., 
SH_SWAP_IN  utilizes  (calls)  MM_SHAP_IH) .  Bells  [20]  pro¬ 
vides  a  aore  detailed  description  of  this  portion  of  the 
Distributed  Meaory  Manager  and  the  extended  instruction  set 
associated  with  it. 

The  Distributed  Memory  Manager  is  also  invoked  through 
its  reaaining  extended  instructions:  MM_&EAD_EV£NTC00NT, 
MHJCICKET,  MM_ADVAHCE,  and  MH_ ALLOCATE.  These  Distributed 
Meaory  Manager  functions  are  discussed  in  detail  by  Strick- 
ler  [  19]. 
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Chapter  TII 

HOI-DISTEIBUTED  SEES EL 


The  Non-Distributed  Kernel  is  the  second  elesent  resid¬ 
ing  in  Level  1  of  our  abstract  system  view  of  the  SASS.  The 
sole  component  of  the  Hon-Distributed  Kernel  is  the  Heaory 
Manager  Process. 

a.  SBBQBI  SABAS m  glfifiSSS 

The  priaary  purpose  of  the  Heaory  Manager  Process  is  the 
aanageaent  of  all  aeaory  resources  within  the  SASS.  These 
include  the  local  and  global  aain  memories,  as  well  as  the 
hard-disk  based  secondary  storage.  A  dedicated  Heaory  Man¬ 
ager  Process  exists  for  every  CPU  in  the  systea.  Each  CPU 
possesses  a  local  aeaory  where  process  local  segments  and 
shared,  non-writeable  segments  are  stored.  There  is  also  a 
global  aeaory,  to  which  every  CPU  has  access,  where  the 
shared,  writeable  segments  are  stored.  It  is  necessary  to 
store  these  shared,  writeable  segaents  in  the  global  aeaory 
to  ensure  that  a  current  copy  exists  for  every  access. 

The  Heaory  Manager  Process  is  tasked  by  other  processes 
within  the  Kernel  domain  (via  Signal  and  Hait)  to  perform 
memory  aanageaent  functions.  These  basic  functions  include 
the  allocation/deallocation  of  local  and  global  aeaory  and 
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of  secondary  storage,  and  the  transfer  of  segsents  between 
the  local  and  global  aeaory  and  between  secondary  storage 
and  the  aain  aeaories.  The  extended  instruction  set  provid¬ 
ed  by  the  Meaory  Manager  Process  includes:  CBEATE_E*TBT, 
DELETE_EHTRT,  ACTIVATE,  DEACTIVATE,  SHAP.IB,  and  SBAPJJUT. 
These  instructions  correspond  one  to  one  with  those  of  the 
Distributed  Memory  Manager  Module.  The  systea  wide  data 
bases  utilized  by  all  Meaory  Manager  Processes  are  the  Glo¬ 
bal  Active  Segment  Table  (G_A5T) ,  the  Alias  Table,  the  Disk 
Bit  Hap,  and  the  Global  Meaory  Bit  Map.  The  processor  local 
databases  used  by  each  Meaory  Manager  Process  are  the  Local 
Active  Segment  Table  (L.AST) ,  and  the  Local  Meaory  Bit  Hap. 
Gary  and  Moore  [5]  provide  a  detailed  description  of  the  Me¬ 
aory  Manager,  its  extended  instruction  set,  and  its  databas¬ 
es. 

A  suaaary  of  the  extended  instruction  set  created  by  the 
coaponents  of  the  Security  Kernel  is  provided  by  Figure  10. 
One  might  question  the  prudence  of  omitting 
PHTS_PREBHPT_HANDLEB  and  VIBT_PBEEHPT_HAMDLEH  (viz.,  the 
handler  routines  for  physical  and  virtual  interrupts)  from 
the  extended  instruction  set  as  both  of  these  interrupts  aay 
be  raised  (viz.,  initiated)  from  within  the  Kernel.  A  deci¬ 
sion  was  made  to  not  classify  these  handlers  as  "extended 
instructions"  since  they  are  only  executed  as  the  result  of 
a  physical  or  virtual  interrupt  and  as  such  cannot  be  di¬ 
rectly  invoked  (viz. ,  "called")  by  any  aodule  in  the  systea. 
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1  smeary  of  the  databases  utilized  by  Kernel  nodules  is 
presented  in  Figure  11. 
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Figure  10:  Extended  Instruction  Set 
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Chapter  Till 
SYSTEM  HABD BABE 


Level  0  of  the  SASS  consists  of  the  systea  hardware. 
This  hardware  includes:  1)  the  CPO,  2)  the  local  aeaory,  3) 
the  global  aeaory,  4)  the  secondary  storage  (viz.  hard 
dish) ,  and  5)  the  I/O  ports  connecting  the  host  coaputer 
systeas  to  the  SASS.  Since  the  SASS  design  allows  for  a 
aultiprocessor  environaent,  there  nay  exist  aultiple  CPU's 
and  local  aeaories.  The  target  aachine  selected  for  the  in¬ 
itial  inpleaentation  of  the  systea  is  the  Zilog  Z8001  aicro- 
processor  [22].  The  Z8001  is  a  general  purpose  16-bit,  re¬ 
gister  oriented  aachine  that  has  sixteen  16-bit  general 
purpose  registers.  It  can  directly  address  8M  bytes  of  ne- 
aory,  extensible  to  48H  bytes.  The  Z8Q01  architecture  sup¬ 
ports  aeaory  segaentation  and  two-doaain  operations.  The 
aeaory  segaentation  capability  is  provided  externally  by  the 
Zilog  Z8010  Heaory  Nanageaent  Unit  (MHO) .  The  Z8010  UNO 
[23]  provides  aanagenent  of  the  Z8001  addressable  aeaory, 
dynaaic  segaent  relocation,  and  aeaory  protection.  Heaory 
segaents  are  variable  in  size  froa  256  bytes  to  64K  bytes 
and  are  identified  by  a  set  of  64  Segaent  Descriptor  Regis¬ 
ters,  which  supply  the  inforaation  needed  to  aap  logical  ae¬ 
aory  addresses  to  physcal  aeaory  addresses.  Each  of  the  64 


Descriptor  Registers  contains  a  16-bit  base  address  field, 
an  8-bit  limit  field,  and  an  8-bit  attribute  field.  Unfor¬ 
tunately,  the  Z8001  hardware  was  not  available  for  use  dur¬ 
ing  system  development.  Therefore,  all  work  to  date  has 
been  coapleted  through  utilization  of  the  Z8002  non-segaent- 
ed  version  of  the  Z8000  aicroprocessor  faaily  £22].  The  ac¬ 
tual  hardware  used  in  this  iapleaentation  is  the  Advanced 
Micro  computers  Aa96/4116  MonoBoard  Computer  [1]  containing 
the  AmZ8002  sixteen  bit  non-segaented  aicroprocessor.  This 
computer  provides  32K  bytes  of  on-board  BAM,  8k  bytes  of 
PROM/BOM  space,  two  RS232  serial  I/O  ports,  24  parallel  I/O 
lines,  and  a  standard  INTEL  Multibus  interface.  The  general 
structure  of  the  design  has  been  preserved  by  simulation  of 
the  segaentation  hardware  in  software.  Ibis  software  NHU 
Image  (see  Figure  12)  is  created  as  a  database  within  the 
Inner  Traffic  Controller. 

The  MMU  Image  is  a  processor-local  database  indexed  by 
DBR_No.  Each  DBR_Mo  represents  one  record  within  the  MMU 
Image.  Each  record  is  an  exact  software  copy  of  the  Segaent 
Descriptor  Register  set  in  the  hardware  MMU.  Each  eleaent 
of  this  software  MMU  Image  is  in  the  same  fora  utilized  by 
the  special  I/O  instructions  to  load  the  hardware  MMU.  Each 
DBR  record  is  indexed  by  segaent  number  (Segment_No) .  Each 
Segaent.No  entry  is  composed  of  three  fields:  Base_Addr, 
Limit,  and  Attributes.  Base.Addr  is  a  16-bit  field  which 
contains  the  base  address  of  the  segaent  in  physcal  memory. 


49 


Segment 

NO. 

I 

I 

I 

I 

¥ 


DBfi  NO - > 


I  Basejkddr 

I  Lis  it 

1 

Attributes  | 

|  — —  -- 
1 

1 

i 

1 - 
1 

1 

i 

1  -■ - 

1 

1 

1 

•  •  •  | 

1 - 

1 

1 

-  i 

i 

1 

1 

i 

1 

1  ..•••• 

1 

1  . 

i 

I 


- , - 

I 

I 

¥ 

(entries  for  one  DBB  •) 


I 


Figure  12:  Neaory  Management  Unit  (HHO)  laage 


Liait  is  an  8-bit  field  that  specifies  the  nuaber  of  conti¬ 
guous  blocks  of  aeaory  occupied  by  the  segaent.  Attributes 
is  an  8-bit  field  representing  the  eight  flags  which  specify 
the  segaent* s  attributes  (e.g.,  "read",  "execute",  "write", 
etc.)  . 
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Chapter  IZ 
S OH Hi BY 

An  extended  overview  of  the  current  SASS  design  has  been 
presented.  The  four  sajor  levels  of  abstraction  comprising 
the  SASS  systen  have  been  identified,  and  the  sajor  compo¬ 
nents  of  each  level  have  been  discussed.  The  extended  in¬ 
struction  set  provided  by  the  SASS  Kernel  was  also  defined. 
The  actual  details  of  this  ispleaentation  are  described  by 
Striclcler  [  19  ]. 
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PART  C 

THE  DESIGH  AID  IHPLBHBf TATION  OF  THE  MEMORY 
MANAGER  FOB  A  SECORE  ARCHIVAL  STORAGE  STSTEH 


This  section  contains  updated  excerpts  froa  a  Naval  Postgra- 
duaduate  School  MS  Thesis  by  E.  E.  Moore  and  A.  V.  Gary  [5], 
The  origins  of  these  excerpts  are: 

INTRODUCTION  froa  Chapter  I 
MEMORT  MANAGER  PROCESS  DETAILED  DESIGN  froa  Chapter  III 
STATUS  OF  RESEARCH  froa  Chapter  I? 


Minor  changes  have  been  aade  for  integration  into  this  report 


AO-A109  553  NAVAL  POSTGRADUATE  SCHOOL  MONTEREY  CA  F/0  9/2 

THE  NAVAL  POSTGRADUATE  SCHOOL  SECURE  ARCHIVAL  STORAGE  SYSTEM.  P—£TC<U> 
MAR  81  LA  COX*  R  R  SCHELL*  S  L  PERDUE 

UNCLASSIFIED  NPS52-81-001  _  _ _ NL _ 


Chapter  X 
IITiODOCTIOM 

This  thesis  addresses  the  design  and  partial  implementa¬ 
tion  of  a  memory  aanager  for  a  aeaber  of  the  faaily  of  se¬ 
cure,  distributed,  nulti-microprocessor  operating  systems 
designed  by  Bichardson  and  0* Connell  [7].  The  aeaory  aanag¬ 
er  is  responsible  for  the  secure  aanageaent  of  the  aain  me¬ 
mory  and  secondary  storage.  The  aeaory  aanager  design  was 
approached  and  conducted  vith  distributed  processing,  multi¬ 
processing,  configuration  independence,  ease  of  change,  and 
internal  computer  security  as  primary  goals.  The  problems 
faced  in  the  design  were: 

1)  Developing  a  process  which  would  securely  man¬ 
age  files  in  a  multi- processor  environment. 

2)  Ensuring  that  if  secondary  storage  was  inadver¬ 
tantly  damaged,  it  could  usually  be  recreated. 

3)  Binimizing  secondary  storage  accesses. 

4)  Proper  parameter  passing  during  interprocess 
communication. 

5)  Developing  a  process  vith  a  loop-free  structure 
which  is  configuration  independent. 
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6)  Designing  databases  which  optimize  the  memory 
management  functions. 

The  proper  design  and  iapleientation  of  a  aesory  aanage¬ 


aent  process  is  vital  because  it  serves  as  the  interface 
between  the  physical  storage  of  files  in  a  storage  systaa 
and  the  logical  hierarchical  file  structure  as  viewed  by  the 
user  (viz.,  the  file  systea  supervisor  design  by  Parks  [9]. 
If  the  aeaory  aanager  process  does  not  function  properly, 
the  security  of  that  systea  cannot  be  guaranteed. 

The  secure  faaily  of  operating  systeas  designed  by  Bich- 
ardson  and  O'Connell  is  composed  of  two  primary  modules,  the 
supervisor  and  the  security  kernel.  &  subset  of  that  systea 
was  utilized  in  the  design  of  the  Secure  Archival  Storage 
Systea  (SASS) .  The  design  of  the  SASS  supervisor  was  ad¬ 
dressed  by  Parks  [9],  while  the  security  kernel  was  ad¬ 
dressed  concurrently  by  Coleman  [2].  The  SASS  security  ker¬ 
nel  design  is  coaposed  of  two  parts,  the  distributed  kernel 
and  the  non-distributed  kernel.  The  design  of  the  distribut¬ 
ed  kernel  was  conducted  by  Coleman  [2],  and  processor  man¬ 
agement  was  implemented  by  Beitz  [12].  This  thesis  presents 
the  design  and  implementation  of  the  non-distributed  kernel. 
In  the  SASS  design,  the  non-distributed  kernel  consists 
solely  of  the  memory  aanager. 

The  design  of  the  aeaory  aanager  and  its  data  bases  was 
completed.  The  initial  code  was  written  in  PLZ/SIS,  but 
could  not  be  compiled  due  to  the  lack  of  a  PLZ/SIS  compiler. 
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k  thread  of  the  high  level  code  was  selected,  hand  coapiled 
into  PLZ/4SH,  and  run  on  the  Z3000  developmental  nodule. 
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Chapter  XI 

HEHOBI  HAIAGEB  PBOCESS  D MULED  DESIGH 

A.  imsQ&iifii 

The  aeaory  eanager  is  responsible  for  the  aanageaent  of 
both  eain  aeaory  (local  and  global)  and  secondary  storage. 
It  is  a  non-distributed  portion  of  the  kernel  with  one  aeao- 
ry  aanager  process  existing  per  physical  processor.  The  ae- 
aoty  aanager  is  tasked  (via  signal  and  wait)  to  perfora  ae- 
aory  aanageaent  functions  on  behalf  of  other  processes  in 
the  system.  The  aajor  tasks  of  the  aeaory  aanager  are  :  1) 

the  allocation  and  deallocation  of  secondary  storage,  2)  the 
allocation  and  deallocation  of  global  and  local  aeaory,  3) 
segment  transfer  froa  local  to  global  aeaory  (and  vice  ver¬ 
sa)  ,  and  4)  segaent  transfer  froa  secondary  storage  to  aain 
aeaory  (and  vice  versa) .  There  are  ten  service  calls  (via 
signal)  which  task  the  aeaory  aanager  Process  to  perfora 
these  functions.  The  ten  service  calls  are: 

CBEATE_EMTRY 

deleteIeitby 

ACTIVATE 
DEACTIVATE 
SHIP  IN 
SHAP’OOT 
DEACTIVATE  ALL* 

HOVE  TO  GLOBAL* 

HOVE  TO_LOCAL* 

UPDATE* 
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Upon  completion  of  the  service  request,  the  aesory  manager 
returns  The  results  of  the  operation  to  the  waiting  process 
(via  signal) .  It  then  blocks  itself  until  it  is  tasked  to 
perfora  another  service.  The  hardware  configuration  aanaged 
by  the  aeaory  aanager  process  is  depicted  in  Figure  13.  The 
shared  data  bases  used  by  all  aeaory  aanager  processes  are 
the  Global  Active  Segment  Table  (G_ASI) ,  the  Alias  Table, 
the  Disk  Bit  Map,  and  the  Global  Meaory  Bit  Map.  The  proces¬ 
sor  local  data  bases  used  by  each  process  are  the  Local  Ac¬ 
tive  segment  Table  (L_AST) ,  the  Meaory  Management  Unit  Imag¬ 
es  and  the  Local  Meaory  Bit  Map. 


*  In  the  current  state  these  service  calls  are  not  implemented 
therefore,  there  are  currently  six  service  calls. 
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SECONDARY 

STORAGE 


b.  fiSSZSI  EAfiAIBIBSS  4IC  Qfi£l£l£iL2 

Several  factors  were  identified  during  the  design  of  the 

aeaory  aanager  process  that  refined  the  initial  kernel  de¬ 
sign  of  Coleaan  [2].  The  two  areas  that  were  aodified,  were 
the  aanageaent  of  the  MHO  iaages  and  the  aanageaent  of  core 
aeaory.  Both  of  these  functions  were  aanaged  outside  of  the 
aeaory  aanager  in  the  initial  design.  The  inclusion  of 
these  functions  in  the  aeaory  aanager  process  significantly 
iaproved  the  logical  structure  of  the  overall  systea  de¬ 
sign.  Additional  design  paraaeters  were  established  to  fa¬ 
cilitate  the  initial  iapleaentation.  These  design  paraae¬ 
ters  need  to  be  addressed  before  the  detailed  design  of  the 
aeaory  aanager  process  is  presented. 

It  was  decided  to  aake  the  block/page  size  of  both  aain 
aeaory  and  secondary  storage  egual  in  size.  This  was  to  sia- 
plify  the  aapping  algoritha  froa  secondary  storage  to  aain 
aeaory  (and  vice  versa) .  In  the  initial  design  the  block/ 
page  size  was  set  to  512  bytes. 

The  size  of  the  page  table  for  a  segaent  was  set  at  one 
page  (non-paged  page  table) .  This  was  to  siaplify  iapleaen- 
tation,  and  had  a  direct  bearing  on  the  aaxiaun  segaent  size 
supported  in  the  aeaory  aanager.  For  exaaple,  a  page  size 
of  256  bytes  will  address  a  aaxiaua  segaent  size  of  32,768 
bytes,  while  a  page  size  of  512  bytes  will  address  a  segaent 
size  of  131,072  bytes. 
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The  size  of  the  alias  table  was  set  to  oae  page 
(non-paged  alias  table) *  The  auaber  of  entries  that  the 
alias  table  will  support  is  liaited  by  the  size  of  the  page 
table  (viz.,  a  page  size  of  512  bytes  will  support  up  to  42 
entries  in  the  Alias  Table) . 

In  the  original  design ,  the  aain  aeaory  allocation  was 
external  to  the  aeaory  aanager.  This  was  due  to  the  parti¬ 
tioned  aeaory  aanageaent  scheae  outlined  by  Parks  [9]  and 
Coleaan  £2].  Zn  the  current  design,  all  address  assignaent 
and  segaent  transfer  are  aanaged  by  the  aeaory  aanager.  This 
design  choice  enhanced  the  generality  of  the  design,  and 
provided  support  for  any  aeaory  aanageaent  scheae  (either  in 
the  aeaory  aanager  or  at  a  higher  level  of  abstraction) . 
However,  the  current  design  still  has  a  aaxiaua  core  const¬ 
raint  for  each  process. 

Dynaaic  aeaory  aanageaent  is  not  iapleaented  in  this  de¬ 
sign.  Each  process  is  allocated  a  fixed  size  of  physical 
core.  However,  it  is  not  a  linear  allocation  of  physical 
aeaory.  The  design  supports  the  aaxiaua  sharing  of  segaents 
in  local  and  global  aeaory.  All  segaents  that  are  not 
shared,  or  shared  and  do  not  violate  the  readers/writers 
problea  will  reside  in  local  aeaory  to  eliainate  the  global 
bus  contention.  The  need  to  coapact  the  aeaory  (because  of 
f ragaentation)  should  be  ainiaal  in  this  design  due  to  the 
aaxiaua  sharing  of  segaents.  If  contiguous  aeaory  is  not 
available,  the  aeaory  aanager  will  coapact  aain  aeaory.  Aft¬ 
er  coapaction,  the  aeaory  can  be  allocated. 
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The  design  decision  to  represent  aeaory  as  one 
contiguous  block  (not  partitioned)  was  Bade  to  support  a  dy¬ 
namic  aeaory  aanageaent  scheme.  Without  dynamic  memory  man¬ 
agement,  the  process'  total  physical  aeaory  can  not  exceed 
the  systems  main  aeaory.  The  supervisor  knows  the  size  of 
the  segments  and  the  size  of  the  process*  virtual  core, 
therefore  it  can  manage  the  swap  in  and  swap  out  to  ensure 
that  the  process*  virtual  core  has  not  been  exceeded. 

In  the  original  design,  the  user's  process  inner-traffic 
controller  maintained  the  software  images  of  the  aeaory  man- 
ageaent  unit.  This  design  required  the  aeaory  aanager  to  re¬ 
turn  the  appropriate  aeaory  aanageaent  data  (viz.,segaent 
location)  to  the  kernel  of  the  user's  process.  in  the  cur¬ 
rent  design,  the  software  iaages  of  the  HHO  are  maintained 
by  the  aeaory  aanager.  k  descriptor  base  pointer  is  provid¬ 
ed  for  the  inner-traffic  controller  to  multiplex  the  process 
address  spaces.  The  HHU  iaage  data  base  does  not  need  to  be 
locked  (to  prevent  race  conditions)  due  to  the  fact  that 
process  interrupts  are  aasked  in  the  kernel.  Thus,  if  the 
memory  aanager  (a  kernel  process)  is  running  then  no  other 
process  can  access  the  MHO  iaage. 

The  system  initialization  process  has  not  been  addressed 
to  date.  However,  this  design  has  made  some  assuaptions 
about  the  initial  state  of  the  system.  Since  the  memory 
aanager  handles  the  transfer  of  segments  froa  secondary  sto¬ 
rage  to  main  memory,  it  is  likely  to  be  one  of  the  first 


processes  created.  The  aeaory  aanager's  core  iaage  will  con¬ 


sist  of  its  pure  code  and  data  sections.  The  ainiaal  ini¬ 
tialization  of  the  aeaory  aanager's  data  bases  are  entries 
for  the  systea  root  and  the  supervisor's  segaents  in  the 
G_AST  and  L_AST  (s) ,  and  the  initializaton  of  the  BHU  iaages 
with  the  kernel  segaents.  The  current  design  does  not  call 
for  an  entry  in  the  G_AST  or  L_AST  for  the  kernel  segaents. 
However,  when  systea  generation  is  designed  this  will  have 
to  be  readdressed. 

The  original  [2]  aeaory  aanager  databases  have  been  re¬ 
fined  by  this  thesis  to  facilitate  the  aeaory  aanageaent 
functions.  The  aajor  refineaents  of  the  global  and  local  ac¬ 
tive  segaent  tables  are  outlined  in  the  following  section. 

C.  sm  2AS5S 

*•  sisbal  kstiis.  Sggssaft  x&kls 

The  Global  Active  Segaent  Table  (see  Figure  14)  is  a 
systea  wide,  shared  data  base  used  by  aeaory  aanager  pro¬ 
cesses  to  aanage  all  active  segaents.  A  lock/unlock  aechan- 
isa  is  utilized  to  prevent  any  race  conditions  froa  occur¬ 
ring.  The  signalling  process  locks  the  G_AST  before  it 
signals  the  aeaory  aanager.  This  is  done  to  prevent  a  dead¬ 
ly  eabrace  froa  occurring  between  aeaory  aanager  processes, 
and  also  to  siaplify  synchronization  between  aeaory  aanag- 
ers.  The  entire  G_AST  is  locked  in  this  design  to  siaplify 
the  iapleaentation  (vice  locking  each  individual  entry). 
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Figure  14:  Global  Active  Segment  Table 
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The  G_AST  size  is  fixed  at  compile  time.  The  size  of 
the  G_AST  is  the  product  of  the  G_AST  record  size,  the  aaxi- 
aua  number  of  processes  and  the  number  of  authorized  known 
segments  per  process.  Although  the  G_AST  is  of  fixed  size, 
it  is  plausible  to  dynamically  aanage  the  entries  as  pro¬ 
posed  by  Bichardson  and  O'Connell  [7].  The  current  aeaory 
aanager  design  could  be  extended  to  include  this  dynaaic 
aanageaent. 

The  Onique_ld  field  is  a  unique  segaent  identification 
nuaber  in  the  G_AST.  This  field  is  four  bytes  wide  and  will 
provide  over  four  billion  identification  numbers.  A  design 
choice  was  aade  not  to  aanage  the  reallocation  of  the  uni- 
gue_id's.  Thus  when  a  segment  is  deleted  froa  the  system, 
the  unique_id  is  not  reused. 

The  Global_Address  field  is  used  to  indicate  if  a  seg¬ 
ment  resides  in  global  or  local  memory.  If  not  null,  it  con¬ 
tains  the  global  aeaory  base  address  of  a  segaent.  A  null 
entry  indicates  that  the  segment  might  be  in  local  memo¬ 
ry  (s)  . 

The  Processors_L_ASTE_#  field  is  used  as  a  connected 
processors  list.  The  field  is  an  array  structure,  indexed 
by  Processor_Id.  It  identifies  which  L_AST  the  segment  is 
active  in,  and  provides  the  index  into  each  of  these  tables. 
The  design  choice  of  maintaining  an  entry  in  the  L_AST  for 
all  locally  active  segments  implies  that  if  all  entries  in 
the  Processors_L_ASTE_#  field  are  null,  the  segaent  is  not 
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active  and  can  be  reaoved  froa  the  G_ASI  (viz.,  no  proces¬ 
sors  are  connected) . 

The  Plag_Bits  field  consists  of  the  written  bit,  and 
the  writable  bit.  The  written  bit  is  set  when  a  segaent  is 
swapped  out  of  aeaory,  and  the  HHO  iaage  indicates  that  it 
has  been  written  into.  The  writable  bit  is  set  during  seg- 
aent  loading  to  indicate  that  some  process  has  write  access 
to  that  segaent. 

If  an  active  segaent  is  a  leaf,  the  G_AST£_*. Parent 
field  provides  a  bach  pointer  to  the  G_AST  index  of  its  pa¬ 
rent.  This  bach  pointer  to  the  parent  is  iaportant  during 
the  creation  of  a  segaent.  If  a  reguest  is  received  to 
create  a  segaent  which  has  a  leaf  segaent  as  its  parent, 
then  an  alias  table  has  to  be  created  for  that  parent. 
Also,  the  alias  table  of  the  parent's  parent  needs  to  be  up¬ 
dated  to  reflect  the  existence  of  the  newly  created  alias 
table  (see  Pigure  15).  The  indirect  pointer  shown  is  the 
bach  pointer  to  the  parent  via  the  G_ASI. 

The  Ho_Active_la_HeaoEy  field  is  a  count  of  the  nuaber 
of  processes  that  have  the  segaent  in  global  aeaory.  It  is 
used  during  swap  out  to  deteraine  if  the  segaent  can  be  re¬ 
aoved  froa  global  aeaory. 

The  No_Active_Dependents  field  is  a  count  of  the  nuaber 
of  active  leaf  segaents  that  are  dependent  on  this  entry 
(viz.,  require  that  this  segaent  reaain  in  the  G_AST)  .  Each 
tiae  a  process  activates  or  deactivates  a  dependent  segaent 
this  field  is  increaented  or  decreaented. 
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Figure  15:  Alias  Table  Creation 
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The  Size  field  is  the  size  of  the  segaent  in  bytes.  The 
Page_Table_location  field  is  the  disk  location  of  the  page 
table  for  a  segaent,  and  the  Alias.Table.Location  field  is 
the  disk  location  of  the  alias  table  for  the  segaent.  The 
Alias.Table  field  can  be  null  to  indicate  that  no  alias  ta¬ 
ble  exists  for  the  segaent. 

The  last  three  fields  are  used  in  the  aanageaent  of  ev- 
entcounts  and  sequencers  [  12].  The  Sequencer  field  is  used 
to  issue  a  service  nuaber  for  a  segaent.  The  Instance.l 
field  and  lnstance_2  field  are  eventcounts  (i. e. ,  are  used 
to  indicate  the  next  nuaber  of  occurances  of  soae  event) . 

2.  La sal  isiiis  Segaent  Xafcls 

The  Local  Active  Segaent  Table  (see  Figure  16)  is  a 
processor  local  data  base.  The  L.AST  contains  the  character¬ 
istics  (viz.,  segaent  nuaber,  access)  of  each  locally  active 
segaent.  An  entry  exists  for  each  segaent  that  is  active  in 
a  process  "loaded"  on  this  CPU  and  in  local  aeaory.  The 
first  field  of  the  L.AST  contains  the  aeaory  address  of  the 
segaent.  If  the  segaent  is  not  in  aeaory,  this  field  is 
used  to  indicate  whether  the  L.AST  entry  is  available  or  ac¬ 
tive.  The  Segaent.No/Access  field  is  a  coabination  of  seg¬ 
aent  nuaber  and  authorized  access.  It  is  an  array  of  records 
data  structure  that  is  indexed  by  DBB.i.  The  first  record 
eleaent  (viz.,aost  significant  bit)  is  used  to  indicate  the 
access  (read  or  read/write)  peraitted  to  that  segaent.  The 
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second  record  element  (viz.,  the  next  seven  bins)  is  used  to 


indicate  the  segment  number.  &  null  segment  number  indi¬ 
cates  that  the  process  does  not  have  the  segment  active. 

Index  # 


Memory 

Segment _#/Access_Auth 

Addr 

DBH_0 

DBB.1 

DBB_2 

DBS. 3 

DBS.  4 

DBB.5 

Figure  16:  Local  Active  Segaent  Table 

3.  Alia a  lafels 

The  alias  table  (see  Figure  17)  is  a  memory  manager  data 
base  which  is  associated  with  each  non  leaf  segaent  in  the 
kernel.  An  aliasing  scheme  is  used  to  prevent  passing  sys¬ 
temwide  information  (unique.id.)  out  of  the  kernel.  Seg¬ 
ments  can  only  be  created  through  a  mentor  segaent  and  entry 


69 


number  into  the  eentor's  alias  table.  Mhen  a  segment  is 
created,  an  entry  aust  be  aade  in  its  aentor  segaent's  alias 
table.  Thus  the  aentor  segment  aust  be  known  before  that 


segaent  can  be  created. 


Entry_# 


v 


Onique.ID 


Size 


Class 


Page  Table 
Location 


Alias  Table 
Location 


Figure  17:  Alias  Table 

The  alias  table  consists  of  a  header  and  an  array  struc¬ 
ture  of  entries.  The  header  has  two  "pointers"  (viz.,  disk 
addresses) ,  one  that  links  the  alias  table  to  its  associated 
segsent  and  one  that  links  the  alias  table  to  the  aentor 
segaent's  alias  table.  The  header  is  provided  to  support  the 
re-construction  of  the  file  systea  after  a  systea  crash  due 

-  70  - 


to  device  I/O  errors.  It  is  not  used  at  all  during  norsal 
operations.  Each  entry  in  the  array  structure  consists  of 
five  fields  for  identifying  the  created  segments.  The  Oni- 
que_Id  field  contains  the  unique  identification  nuaber  for 
the  segaent.  The  Size  field  is  used  to  record  the  size  of 
the  segaent.  The  Class  field  contains  the  appropriate  secur¬ 
ity  access  class  of  the  segaent.  The  Page.Table.Location 
field  has  the  dish  address  of  the  page  table.  A  null  entry 
indicates  a  zero-length  segaent.  The  Alias jTable.Location 
field  has  the  dish  address  of  the  alias  table  for  the  seg¬ 
aent.  A  null  entry  indicates  that  the  segaent  is  a  leaf 
segaent. 

flsascz  fluasaisai  flail  iaaaa 

The  Beaory  flanageaent  Unit  Iaage  (BMO.Inage)  is  a  pro¬ 
cessor  local  data  base.  It  is  an  array  structure  that  is  in¬ 
dexed  by  the  DBB_#.  Each  BBU.Iaage  (see  Figure  18)  includes 
a  software  representation  of  the  segaent  descriptor  regis¬ 
ters  (SDB)  for  the  hardware  BBO  [23].  This  is  in  exactly 
the  foraat  used  by  the  special  I/O  instructions  for  loading/ 
unloading  the  BBU  hardware.  The  SDB  contains  the 
Base. Address,  Liait  and  Attribute  fields  for  each  loaded 
segaent  in  the  process'  address  space.  The  Base.Address 
field  contains  the  base  address  of  the  segaents  in  aeaory 
(local  or  global) .  The  Liait  field  is  the  nuaber  of  blochs 
of  contiguous  storage  for  each  segaent  (zero  indicates  one 
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block).  The  Attribute  field  contains  eight  flags.  Five 
flags  are  used  for  protecting  the  segaent  against  certain 
types  of  access,  two  encode  the  type  of  accesses  Bade  to  the 
segaent  (read/vrite) ,  and  one  indicates  the  special  struc¬ 
ture  of  the  segaent  [23].  Five  of  the  eight  flags  in  the 
attribute  field  are  used  by  the  aeaory  aanager.  The  "systea 
only"  and  "execute  only"  flags  are  used  to  protect  the  code 
of  the  kernel  froa  aalicious  or  unintentional  aodifications. 
The  "read  only"  flag  is  used  to  control  the  read  or  write 
access  to  a  segaent.  The  "change"  flag  is  used  to  indicate 
that  the  segaent  has  been  written  into,  and  the  "CPO-inhi- 
bit"  flag  is  used  to  indicate  that  the  segaent  is  not  in  ae- 
aory. 

The  last  two  fields  of  the  BBO.Iaage  are  the  BlockjJsed 
field  and  the  Baxiaua.Available.Blocks  field.  These  two 
fields  are  used  in  the  aangeaent  of  each  process'  virtual 
core  and  are  not  associated  with  the  hardware  HBU. 
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Figure  18:  Heaory  Banageaent  Unit  Iaage 
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All  of  the  aeeory  allocation/deallocation  bit  aaps  (see 
Figure  19)  are  basically  the  saae  structure.  Secondary  sto¬ 
rage,  global  aeaory  and  local  aeaory  are  aanaged  by  aeaory 
bit  aaps.  The  Disk_Bit_llap  is  a  global  resource  that  is 
protected  froa  race  conditions  via  the  locking  convention 
for  the  G_AST.  5Uch  bit  in  the  bit  aap  is  associated  with  a 
block  of  secondary  storage.  A  zero  indicates  a  free  block 
of  storage  while  a  one  indicates  an  allocated  block  of  sto¬ 
rage.  The  Globa i_Heaory_Bit_Bap  is  used  to  aanage  global  ae- 
aory.  It  is  a  shared  resource  that  is  protected  froa  race 
conditions  by  the  locking  of  the  G_AST.  The  Lo- 
cal_Heaory_Bit..Hap  is  the  saae  structure  as  the  Glo- 
bal_Seuory_Bit_Hap  and  is  used  to  aanage  local  aeaory.  The 
Local_Beaory_Bit_(!ap  is  not  locked  since  it  is  not  a  shared 
resource  between  aeaory  aanagers. 


74 
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Figure  19:  Heaory  Allocation/Deallocation  Hap 
D.  S45IS  rOHCTIOHS 

The  detailed  source  code  for  the  basic  functions  and 
aain  line  of  the  aeaory  aanager  is  presented  in  Appendix  J. 

In  the  discussion  of  the  aeaory  aanager  design,  a  pseu¬ 
do-code  siailar  to  PLZ/SYS  is  utilized.  The  rationale  for 
using  this  pseudo-code  was  to  provide  a  suaaary  of  the  aeao- 
ry  aanager  source  code,  and  to  facilitate  the  presentation 
of  this  design. 

It  is  assuaed  that  the  aeaory  aanager  is  initialized 
into  the  ready  state  at  systea  generation  (as  previously 
aentioned) .  When  the  aeaory  aanager  is  initially  placed 
into  the  running  state,  it  will  block  itself  (via  a  call  to 
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the  kernel  primitive  Wait) .  8ait  will  return  a  aessage  froa 
a  signalling  process.  This  aessage  is  interpreted  by  the  ae- 
aory  aanager  to  deteraine  the  requested  function  and  its  re¬ 
quired  arguaents.  The  function  code  is  used  to  enter  a  case 
stateaent,  which  directs  the  request  to  the  appropriate  ae- 
aory  aanager  procedure. 

When  the  requested  action  is  coapleted,  the  aeaory  aan¬ 
ager  returns  a  success  code  (and  any  additional  required 
data)  to  the  signalling  process  via  a  call  to  the  kernel 
priaitive  Signal.  This  call  will  awaken  the  process  which 
requested  the  action  to  be  taken*  and  place  the  returned 
aessage  into  that  process*  aessage  queue.  Hhen  that  action 
is  coapleted*  the  aeaory  aanager  will  return  to  the  top  of 
the  loop  structure  and  block  itself  to  wait  for  the  the  next 
request.  The  aain  line  pseudo-code  of  the  aeaory  aanager 
process  is  displayed  in  Figure  20. 


ENTRY 

INITIALIZE  PROCESSOR_LOCAL_ VARIABLES 
DO 

!  CHECK_IF_MSG_QOEUE_EMPTY  1 
VP  ID,  MSG  :*  BAIT 

FUNCTION,  ARGUMENTS  :»  VALIDATE  MSG  (MSG) 

IF  FUNCTION 

CASE  CREATE  ENTRY  THEN 

SUCCESS  CODE  :«  CREATE  ENTRY  (ARGUMENTS) 
CASE  DELETE  ENTRY  THEN 

SUCCESS  CODE  :»  DELETE  ENTRY  (ARGUMENTS) 
CASE  ACTIvIlE  THEN 

SUCCESS  CODE  ACTIVATE  (ARGUMENTS) 

CASE  DEACTIVATE  THEN 

SUCCESS  CODE  :*  DEACTIVATE  (ARGUMENTS) 

CASE  SWAP_IN  THEN 

SUCCESS.CODE  S*  SHAP.IN  (ARGUMENTS) 

CASE  SNAP  OUT  THEN 

SUCC ESS_CODE  :»  SBAP_OUT  (ARGUMENTS) 

CASE  DEACTIVATE  ALL  THiN 

SUCCESS  CODE  :»  DEACTIVATE  ALL  (ARGUMENTS) 
CASE  MOVE  TO  GLOBAL  THEN 

SUCCESS.CODE  :»  MOVE  TO  GLOBAL  (ARGUMENTS) 
CASE  MOVE  TO  LOCAL  THEN 

SUCCESS  CODE  MOVE  TO  LOCAL  (ARGUMENTS) 
CASE  UPDATi  THEN 

SOCCESS^CODB  :*  UPDATE  (ARGUMENTS) 

FI 

SIGNAL  (VP_ID,  SUCCESS_CODE ,  ARGUMENTS) 

OD 

END  MEMORY _N AN AGER_PLZ/SYS  MODULE 


Figure  20:  Heaorj  Manager  Mainline  Code 
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1*  CtfilS. s  4&  Alias  Table  fiaitl 

Create_Entry  is  invoiced  when  a  user  desires  to  create  a 
segment.  A  segeent  is  created  by  allocating  secondary  sto¬ 
rage,  and  by  easing  an  entry  (unique_id,  secondary  storage 
location,  size,  classification)  into  it's  mentor  segment's 
alias  table.  This  implies  that  the  mentor  segment  must  have 
an  alias  table  associated  with  it,  and  that  the  mentor  seg¬ 
ment  must  be  active  in  order  to  obtain  the  secondary  storage 
location  of  the  alias  table. 

The  mentor  segment  can  be  in  one  of  two  states.  It  may 
have  children  (viz.,  have  an  alias  table),  or  it  nay  be  a 
leaf  segment  (viz.,  not  have  an  alias  table).  If  the  mentor 
segment  has  children,  it  has  an  alias  table  and  this  alias 
table  can  be  read  into  core,  secondary  storage  can  be  allo¬ 
cated,  and  the  data  can  be  entered  into  the  alias  table.  If 
the  mentor  segment  is  a  leaf,  an  alias  table  must  be  created 
for  that  segment  before  it  (the  alias  table)  can  be  read 
into  core  and  data  entered  into  it  (see  Figure  15). 

The  pseudo-code  for  CBEATE_EETBI  PBOCEOUBE  is  presented 
in  Figure  21.  The  arguments  passed  to  Create_Entry  are  the 
index  into  the  G.AST  for  the  mentor  segment,  the  entry  num¬ 
ber  into  its  alias  table,  the  size  of  the  segment  to  be 
created,  and  the  security  access  class  of  that  segment.  The 
return  parameter  is  a  success  code,  which  would  be 
Nseg_createdN  for  a  successful  segment  creation. 
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CREATE  ENTBY  PROCEDURE  (PAB.INDEX  HOED,  ENTRY.*  HOED, 

SIZE  NOE D,  CLASS  ~BYTE) 

RETURNS  (SUCCESS  CODE  BYTE) 

LOCAL  BLKS  WORD ,  PAGE_TABLE_LOC  HOED 
ENTRY 

I?  ALIAS  TABLE  DOES.NOT  EXIST  THEN 
SUCCBSS.CODE  :*  CREATE. All AS .TABLE 
IF  SUCCESS  CODE  <>  VALID  THEN  BETOEN 
FI 
FI 

BLKS  :=  CALC UL ATE. NO.BLKS.BEQ  (SIZE) 

SUCCESS. CODE  :»  B BAD. ALIAS.T ABLE  ( 

G  AST[  PAB. INDEX  ].  ALIAS  TABLE  LOC) 

IF  SUCCESS  CODE  <>  VALID  THEN  RETURN 
FI 

SUCCESS. CODE  .*  CHECK  DUP  ENTRY  1  in  alias  table  I 
IF  SUCCESS  CODE  <>  VALID  THEN  BETUBN 

FI 

SUCCESS  CODE,  PAGE  TABLE  LOC  :*  ALLOC  SEC  STORAGE  (BLKS) 
IF  SUCCESS  CODE  <>  VALID  THEN  BETUBN 

FI 

UPDATE  ALIAS  TABLE  (ENTRY  *,  SIZE,  CLASS,  PAGE  TABLE  LOC) 
success.codb":*  WRITE  ALIAS  TABLE  ( 

G_ AS  T[ P A  R.INDEX ] . A  LI AS .T  ABLE  _LOC ) 
IF  SUCCESS .CODE  <>  VALID  THEN  BETUBN 
ELSE  SUCCESS.CODE  :=  SEG  CREATED 
FI 

END  CREATE  ENTRY 


Figure  21:  Create  Entry  Pseudo-code 
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When  invoked,  Create_Entry  will  detereine  which  state 
the  aentor  segment  is  in  (viz.,  if  it  has  an  alias  table). 
If  an  alias  table  does  not  exist  for  the  aentor  segment,  one 
is  created  and  the  alias  table  of  the  aentor  segaent*s  pa- 
rent  is  updated.  The  alias  table  is  read  into  core  and  a 
duplicate  entry  check  is  Bade,  if  no  duplicate  entry  exists, 
the  segaent  size  is  converted  froa  bytes  to  blocks,  and  the 
secondary  storage  is  allocated  for  non-zero  sized  segments. 
The  appropriate  data  is  entered  into  the  alias  table  and  the 
alias  table  is  then  written  back  to  secondary  storage. 

2.  fialsis  an  Alias  la&ls  fiaici 

Delete_Entry  is  invoked  when  a  user  desires  to  delete  a 
segaent.  &  segaent  is  deleted  by  deallocating  secondary 
storage,  and  by  removing  the  appropriate  entry  floe  the  ali¬ 
as  table  of  its  aentor  segaent  (the  reverse  logic  of 
Create_Entry) .  This  implies  that  the  aentor  segaent  must  be 
active  at  the  tiae  of  deletion.  There  are  three  conditions 
that  can  be  encountered  during  the  deletion  of  a  segaent: 
the  segaent  to  be  deleted  aay  be  an  inactive  leaf  segment, 
an  active  leaf  segaent,  or  a  aentor  segaent. 

If  the  segaent  to  be  deleted  is  an  inactive  leaf  segaent 
(viz.,  ha3  been  swapped  out  of  core,  and  does  not  have  an 
entry  in  the  G_AST) ,  the  secondary  storage  can  be  deallocat¬ 
ed  and  the  entry  deleted  froa  the  aentor  segment's  alias  ta¬ 
ble.  If  the  segaent  is  an  active  leaf  segaent,  the  segment 
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must  £irst  be  swapped  out  of  core  and  deactivated  before  it 
can  be  deleted.  This  entails  signalling  the  memory  manager 
of  each  processor,  in  which  the  segment  is  active,  to  swap 
out  and  deactivate  the  segment. 

If  the  segment  to  be  deleted  is  a  mentor  segment,  an 
alias  table  exists  for  that  segment  .  If  the  alias  table  is 
empty,  the  secondary  storage  for  the  alias  table  and  the 
segment  can  be  deallocated,  and  the  entry  for  the  deleted 
segment  can  be  removed  from  its  mentor's  alias  table.  If  the 
alias  table  contains  any  entries,  the  segment  cannot  be  de¬ 
leted  because  these  entries  would  be  lost.  If  this  condition 
is  encountered  a  success  code  of  "leaf_segment_exists"  is 
returned  to  the  process  whiev  requested  to  delete  the  entry. 
Due  to  a  confinement  problem  in  "upgraded"  segments,  this 
Success_code  cannot  always  be  passed  outside  of  the  kernel. 
This  implies  that  the  segment  manager  must  strictly  prohibit 
deletion  of  a  segment  with  an  access  class  not  equal  to  that 
of  the  process. 

The  pseudo-code  for  DELETE_EHTBT_PBOCEDOBE  is  presented 
in  Figure  22.  The  parameters  that  are  passed  to  this  proce¬ 
dure  are  the  parent's  index  into  the  G_4ST  and  the  entry 
number  into  the  parent's  alias  table  of  the  segment  to  be 
deleted.  The  alias_table_loc  field  is  checked  to  determine 
the  state  of  the  mentor  segment  (either  a  leaf  or  a  node) , 
and  the  appropriate  action  is  then  taken.  A  success  code  is 
returned  to  indicate  the  results  of  this  procedure. 
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DELETE.ENTBY  PROCEDURE  (  PAR_INDEX  WORD,  ENTRY_#  HORD  ) 
RETURNS  (SUCCESS  CODE  BYTE) 

LOCAL  PAR  INDEX  HORD 
ENTRY 

!  Check  if  the  passed  aentor  segaent  has  an  alias  table.  ! 
IF  S  AST[  PAR  INDEX].  ALIAS  TABLE  LOC  <>  NOLL 
SUCCESS  CODE  :«  READ  ALIAS  TABLE  ( 

G_AST(  PAB_INDEX]. ALI AS_TABLE_LOC) 

ELSE 

SUCCESS.CODE  : =  NO_CHI LD_TO_DELETE 
F! 

IF  SUCCESS  CODE  <>  VALID  THEN  RETURN 
FI 

!  Determine  if  segaent  has  children  in  alias  table  1 
IF  ALIAS  TABLE  NOT  EHPTY  THEN 

SUCCESS_CODE  :*  LEAF_SEGHE NT_ EXISTS 
RETURN  ~  !  Deletion  will  delete  children  ! 

ELSE 

!  Search  G  AST  with  UNIQUE  ID  to  verify  segaent  inactive  ! 
IP  ~ACTIVE_IN_G_AST~  THEN 

!  Check  if  active  in  AST  ! 

IF  ACTIVE  IN  L_AST  THEN 

DEACTIVATE_ALL  (G_AST  INDEX,  L_ASI_INDEX) 

FI 

!  Check  G  AST  to  verify  segaent  inactive  in  other  L_AST*s  I 
IF  ACTIVE  IN  OTHER  L  AST  THEN 

SIGNAL  TO  DEACTIVATE  ALL  (G_ASX_INDEX) 

FI 

FI 

FR2E_SEC_ST0RAGE_0F_SEG_&_ALIAS_IF_EXISTS 
DELETE  ALIAS  TABLE  iNTRY 
FI 

DELETE  ALIASJCABLE  ENTRI 

SUCCESS  CODE  : =  iRITE_ALIAS_TABLE  ( 

G  AST[ PAR  INDEX]. ALIAS  TABLE  LOC) 

IF  SUCCESS_CODE  =  VALID  THEN 

SOCCESS_CODE  :  =  SEG_DELETED 
FI 

END  DELETE  ENTRY 


Figure  22:  Delete  Entry  Pseudo-code 


3.  Asiiiais  a  ssaiaas. 

Activate  is  invoiced  when  a  user  desires  to  make  a  seg¬ 
aent  known  by  adding  a  segment  to  bis  address  space.  A  seg¬ 
ment  is  activated  by  making  an  entry  into  the  L_AST  for  that 
processor,  and  the  G_AST.  The  activated  segaent  could  be  in 
one  of  three  states;  it  could  have  previously  been  activated 
by  another  process  and  have  a  current  entry  in  both  the 
G_AST  and  L_AST,  it  could  have  previously  been  activated  by 
another  process  on  a  different  processor  and  have  an  entry 
in  the  G_AST  but  not  the  L_AST,  or  it  could  be  inactive  and 
have  an  entry  in  neither  the  G_AST  nor  the  L_AST. 

If  the  segment  to  be  activated  already  has  entries  in 
both  the  L_AST  and  G_AST,  these  entries  need  only  be  updated 
to  indicate  that  another  process  has  activated  the  segment. 
The  segment  number  is  entered  into  the  Seg- 
ment_Ho/Access_Auth  field  of  the  L_AST,  and  if  the  segment 
is  a  leaf,  its  mentor's  No_Active_Dependents  field  in  the 
G_AST  is  incremented.  In  this  design,  the  G_AST  is  always 
searched  to  determine  if  the  segaent  has  been  previously  ac¬ 
tivated  by  another  process. 

If  the  segment  to  be  activated  has  an  entry  in  the  G_AST 
but  not  the  L_AST,  an  entry  must  be  made  in  the  L_AST  and 
the  G_AST  must  be  updated.  The  L_AST  is  searched  to  deter¬ 
mine  an  available  index.  The  segment  number  is  entered  into 
the  L_AST,  and  the  index  number  is  entered  into  the  G_AST 
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Processors_L_ASTE_#  field.  If  the  segaent  to  be  activated  is 
a  leaf  segaent,  its  aeator's  Ho_Active_Dependents  field  in 
the  G_AST  is  increaented. 

If  the  activated  segaent  does  not  have  an  entry  in  eith¬ 
er  the  G_AST  or  L..AST,  an  entry  aust  be  aade  in  both.  The 
G_AST  is  searched  to  find  an  available  index,  and  the  entry 
is  aade.  The  L_AST  is  then  searched  to  find  an  available  in¬ 
dex,  and  the  entry  is  aade.  The  L_AST  index  is  then  entered 
into  the  G_AST  Processors.. L_ASTE_#  field.  If  the  activated 
segaent  is  a  leaf,  the  No_Active_Dependents  field  of  its 
aentor*s  S_AST  entry  is  increaented. 

The  pseudo-code  for  ACTIVATE  PROCEDURE  is  presented  in 
Pigure  23.  The  paraaeters  that  are  passed  are  the  DBR_*  of 
the  signalling  process,  the  aentor  segaent ‘s  index  into  the 
G_AST,  the  alias  table  entry  nuaber,  and  the  segaent  nuaber 
of  the  activated  segaent.  The  aentor  segaent  is  always 
checked  to  deteraine  if  it  has  an  associated  alias  table.  If 
it  does  not,  the  success  code  of  "alias_does_not..exist'*  is 
returned.  If  the  alias  table  does  exist,  it  is  read  into 
core  and  the  entry  nuaber  is  used  as  an  index  to  obtain  the 
activated  segaent* s  unigue_id.  The  G_ASI  is  then  searched 
to  deteraine  if  the  segaent  has  already  been  activated.  If 
the  unique.id  is  found,  the  G_AST  is  updated  and  the  L_AST 
is  either  updated  or  an  entry  is  aade  (depending  on  whether 
an  entry  existed  or  not) .  If  the  unigue_id  of  the  segaent 
was  not  found  during  the  search  of  the  G_AST,  an  entry  aust 
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be  aade  in  both  the  G_AST  and  L_JLST.  Activate  returns  the 
activated  segaeat's  classification,  size,  and  handle  to  the 
signalling  process. 
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ACTIVATE  PROCEDURE  (DBS  •  BITE,  PAB  INDEX  MOBD, 

ENTRY  *  HORD,  SEGHENZ  HO  BITE) 
RETURMS  (SUCCESS  CODE  BITE,  RET  G  AST  HANDLE  HANDLE, 

CLASS  BITE,  SIZE  HORD) 

LOCAL  G  INDEX  HORD,  L  INDEX  HORD 
ENTRY 

I  Verify  that  passed  segment  is  a  aentor  segaent  1 
IF  G_AST[  PAR  INDEX].  ALIAS  TABLE  LOC  <>  0  THEN 
SUCCBSS.CODE  :»  READ_1lIAS_TABLE  ( 

G  AST[ PAR  INDEX].  ALIAS  TABLE  LOC) 

ELSE 

SUCCESS  CODE  :*  ALIAS  DOBS  NOT  EXIST 
FI 

IF  SUCCESS  CODE  <>  VALID  THEN  RETURN 
FI 

!  Check  3  AST  to  determine  if  active  I 

SUCCESS JTODE, INDEX  :»  SEARCH  G  AST  (UNIQUE  ID) 

IF  SUCCESS  CODE  *  FOUND  THEN 
IF  SEGHENT_IN_L_AST  THEN 

UPDATE  L  AST~  (SEGHENT  NO) 

ELSE 

HAKE_L_AST_ENTRY  (DBR  # ,  SEGNENT  NO) 

UPDATE  G  AST  (L  INDEX)* 

IF  G_AST[ INDEX  ]. ALIAS  TABLE  LOC  *  NOLL  THEN 

G  AST[  PAR  INDEX].  NO  DEpInDENTS  ACTIVE  *=  1 
PI 
FI 

ELSE 

HAKE  G  AST  ENTRY  (ENTRY  *) 

HAKE  L  AST  ENTRY  (PAR  INDEX,  ENTRY  *) 

FI 

SUCCESS_CODE  :=  S EG_ ACTI V  AT  ED 
END  ACTIVATE 


Figure  23:  Activate  Pseudo-code 
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*.  fisasiiiaia  a  saqisat 

Deactivate  is  invoked  when  a  user  desires  to  reaove  a 
segaent  from  his  address  space.  To  deactivate  a  segment, 
the  memory  aanager  either  reaoves  or  updates  an  entry  in 
both  the  L_AST  and  G_AST.  Deactivate  uses  the  reverse  logic 
of  activate.  Once  a  segaent  is  deactivated,  it  can  only  be 
reactivated  via  its  mentor's  alias  table  as  discussed  in  ac¬ 
tivate.  If  a  process  requests  to  deactivate  a  segaent  which 
has  not  bean  swapped  out  of  the  process'  virtual  core,  the 
aeaory  aanager  swaps  the  segaent  out  and  updates  the  HHO  ia- 
age  before  the  segaent  is  deactivated.  The  segaent  to  be 
deactivated  could  be  in  one  of  three  states;  aore  than  one 
process  could  concurrently  hold  the  segaent  active  in  the 
L_AST,  the  segaent  could  be  held  active  by  one  process  in 
the  L_AST  and  aore  than  one  in  the  G_ASI,  the  segment  could 
be  held  active  by  only  one  process  in  both  the  L_AST  and  the 
G_AST. 

Deactivation  of  leaf  segments  and  aentor  segaents  are 
handled  differently.  Zf  the  segment  is  a  aentor  segaent  and 
has  active  dependents,  it  cannot  be  reaoved  from  the  G_AST 
(even  though  no  process  currently  has  that  segaent  active) . 
This  is  based  on  the  design  decision  which  requires  that  the 
aentor  of  all  active  leaf  segaents  remain  in  the  G_AST  to 
allow  accass  to  its  alias  table.  The  aentor's  alias  table 
aust  be  accessible  when  an  alias  table  is  created  for  a  de- 
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pendent  leaf  segment.  If  a  leaf  segment  is  deactivated*  the 
Ho_Active_Dependents  field  of  its  sentor* s  G_AST  entry  is 
decresent9d.  &  sentor  segment  can  only  be  removed  fros  the 
G_AST  if  no  process  holds  it  active*  and  it  has  no  active 
dependents. 

If  sore  than  one  process  concurrently  hold  a  segment  ac¬ 
tive  in  the  l_AST,  and  one  of  then  signals  to  deactivate 
that  segsent*  the  entry  in  the  L_AST  is  updated.  This  is  ac- 
cosplished  by  nulling  out  the  Segsent.Mo/Access.&uth  field 
of  the  L_AST  for  the  appropriate  process.  If  required*  the 
No_Active_Dependants  field  of  its  aentor  segsent* s  G_AST  en¬ 
try  is  decresented. 

If  only  one  process  holds  the  segsent  active  in  the 
L_AST,  and  that  Process  signals  to  deactivate  the  segsent* 
the  L_AST  entry  for  that  segsent  is  removed.  The  Proces¬ 
sors..  L_ASTE_#  is  updated  and  checked  to  determine  if  there 
are  other  connected  processors.  If  there  are  no  other  con¬ 
nected  processors  and  the  segsent  has  no  active  dependents* 
the  segsent  is  cenoved  fros  the  GjkST.  If  there  are  other 
connected  processors*  the  G_AST  is  updated.  If  the  deacti¬ 
vated  sagaent  is  a  leaf*  the  aentor  segsent* s 
No_Active.Dependents  field  in  the  G_1ST  is  decresented. 

The  pseudo-code  for  OE ACTIVATE  PBOCEOOBE  is  presented  in 
Figure  24.  The  paraaeters  that  are  passed  to  the  acsory  man¬ 
ager  are  the  DBB_#  of  the  signalling  process*  and  the  index 
into  the  G_AST  for  the  segment  to  be  deactivated.  The 
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procedure  first  updates  the  L_AST,  and  then  reaoves  the  en¬ 
try  if  no  local  process  holds  the  segaent  active.  The  G_AST 
is  then  updated,  and  its  aentor  segaent  is  checked  (if  the 
deactivated  segaent  was  a  leaf) ,  to  deteraine  if  it  can  be 
reaoved.  If  no  processes  currently  hold  the  segaent  active, 
and  it  has  no  active  dependents,  the  segaent  is  reaoved  froa 


DEACTIVATE  PROCEDURE  (DBH_#  BYTE,  PAR_INDEX  HOED) 
RETURNS  (SUCCESS  CODE  BYTE) 

LOCAL  INDEX  WORD 
ENTRY 

!  Check  if  segaent  is  in  core  ! 

IP  G_AST( INDEX ]. NO_ACTIVE_IN_aEHOHY  <>  0  THEN 

I "check  NNU  image  to  deter line  if  in  local  memory 
IP  IN  LOCAL  BEHORY  THEN 

SUCCESS.CODE  :=  OUT  (DBR_#,  INDEX) 

PI 

PI 

!  Remove  process  segment_no  entry  in  L_ AST  I 

L  AST[ L  INDEX J.SEGHENT  NO/ACCESS  AUTH[ DBR  # ]  *  0 
CHECK_I?_ACTIVS_IN_L_AST  (L_AST_INDEX) 

IP  NOT  ACTIVE  IN  L  AST  THEN 

L  AST[L  INDEX"].  MEHORY  ADDR  :»  AVAILABLE 
PI 

!  Check  if  deleted  segaent  Has  a  leaf  ! 

IF  S  AST[  INDEX  ].G  ASTE  *  PAR  <>  0  THEN 

G_ASTC PAR_INDEX3.no J)EPENDENTSJkCTIVE  -»  1 
!  Determine  if  parent  can  be  removed  ! 

CHECK  P0R_REH0VAL  (PAR.INDEX) 

PI 

!  Detenine  if  deactivated  segaent  can  be  removed  ! 
CHECK  POR  REMOVAL  (INDEX) 

SUCCESS  CODE  :*  SEG  DEACTIVATED 
END  DEACTIVATE 


Figure  24:  Deactivate  Pseudo-code 


5.  Ssae  a  Ssaasai  la 

SWAP_IN  is  invoked  when  a  user  desires  to  swap  a  seg- 
aent  into  aain  aeaory  (global  or  local)  £roe  secondary  sto¬ 
rage.  A  segaent  is  swapped  into  aain  aeaory  by  obtaining  the 
secondary  storage  location  of  its  page  table  froa  the  G_AST, 
allocating  the  required  aaount  of  aain  aeaory,  and  reading 
the  segaent  into  the  allocated  aain  aeaory.  The  segaent  aust 
be  active  before  it  can  be  swapped  into  core,  and  the  re¬ 
quired  aain  aeaory  space  aust  be  available.  Three  conditions 
can  be  encountered  during  the  invocation  of  SHAP_IM.  The 
segaent  can  already  be  located  in  global  aeaory,  the  segaent 
can  already  be  located  in  one  or  aore  local  neaories,  or  the 
segaent  aay  only  reside  in  secondary  storage. 

If  the  segaent  is  not  in  local  or  global  aeaory,  local 
aeaory  is  allocated,  the  segaent  is  read  into  the  allocated 
aeaory,  and  the  appropriate  entries  are  aade  in  the  UHU  ia- 
age,  the  L.AST  and  the  G_AST.  If  the  segaent  is  already  in 
global  aeaory,  it  can  be  assuaed  that  the  segaent  is  shared 
and  writable.  In  this  case  the  only  required  actions  are  to 
update  the  G_AST  and  L_AST .  The  Mo_Active_In_Meaory  field  of 
the  G_AST  entry  is  increaented,  and  the  BHQ  image  is  updated 
to  reflect  the  swapped  in  segaent* s  core  address  and  attri¬ 
butes. 

If  the  segaent  already  resides  in  one  or  aore  local  ae- 
aories,  it  aust  be  determined  if  the  segaent  is  "shared"  and 
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"writable11.  A  segment  is  "shared"  if  it  exists  in  sore  than 
one  local  aeaory.  &  segment  is  "writable"  if  one  process  has 
write  access  to  that  segment.  If  the  segment  is  not  shared 
or  not  writable  and  in  local  memory,  the  appropriate  entries 
are  updated  in  the  MHO  image,  the  L_AST,  and  the  G_AST.  If 
the  segment  does  not  reside  in  local  aeaory,  the  required 
amount  of  local  memory  is  allocated,  the  segment  is  read 
into  the  allocated  aeaory,  and  the  appropriate  entries  are 
made  in  the  HMD  image,  the  L_AS T,  and  the  G_AST. 

If  the  segment  is  shared,  writable,  and  in  local  aenory, 
the  segment  must  be  moved  to  global  aeaory.  If  the  segment 
is  not  in  the  aeaory  manager's  local  aeaor  y,  it  signals 
another  aeaory  aanager  to  aove  the  segment  to  global  aeaory. 
After  the  segment  is  aoved  to  global  aeaory,  the  aeaory  man- 
ager  signals  all  of  the  connected  aeaory  manager's  to  update 
their  L_AST  and  MHO  data  bases.  When  all  local  data  bases 
are  current,  the  aeaory  aanager  updates  the  G^AST  and  re¬ 
turns  a  success  code  of  seg_activated. 

The  pseudo-code  for  SHAP.IN  PHOCEDCJHE  is  presented  in 
Figure  25.  The  arguments  passed  to  SWAP_IN  are  the 
G_AST_IHDEX  of  the  segment  to  be  aoved  in,  the  process' 
DBB.4,  and  the  access  authorized.  SMAP.IN  will  convert  the 
segaent  size  from  bytes  to  blocks,  and  verify  that  the  pro¬ 
cess'  core  will  not  be  exceeded.  If  the  virtual  core  will 
be  exceeded,  a  success  code  of  "core_space_exceeded"  will  be 
returned.  If  write  access  is  permitted,  the  writable  bit  is 
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set.  Checks  are  then  peri'oraed  to  deteraiae  the  segaent* 
storage  location  (local  or  global) ,  and  the  appropriate  ac 
tion  is  taken. 


T 

•1 


1 


i 

\ 

i 

\ 


-  93  - 


( 


S  WAP.IN  PBOCED  CJR  S  (INDEX  HOSDf  DBfi_#  BITE, 

ACCESS  AUTH  BYTE) 

RETORNS  ( SO CC ESS  CODE  BYTE) 

LOCAL  L.INDEX  WORD,  BLKS  WORD 
ENTRY 

BLKS  CALCOLATE  NO.  OF  BLKS  (G  AST[  INDEX  ].  SIZE) 
SUCCESS  CODE  :*  CHECK~MAX.LINEAR.CORE  (BLKS) 

IF  SUCCESS. CODE  *  VIRTUAL.LINEAfl.CORE.FULL  THEN 
RETURN 
FI 

G.ASTf  I NDEX ].  NO. SEG MEN TS.IN.M EMORY  ♦  =  1 

IF  ACCESS.AUTH  *  WRITE  THEN 

G  AST[INDEX  ]. FLAG  BITS  :®  WRITABLE  BI T  SET 
FI 

!  Determine  if  segment  can  be  put  in  local  memory  ! 

IP  G  AS  T£  INDEX].  FLAG  BITS  AND  WBITABLE.MASK  =  0 
ORIP”  G_AST[  INDEX  ].  NO.ACTIVE.IN.MBMORY  <=  1  THEN 
I  Determine  if  already  in  local  memory  ! 

CHECK  LOCAL.MEMORI  (L.AST.I  NDEX) 

IF  NOT.IN.LOCAL  M EMORY  THEN 

ALLOCATE  LOcIl  MEMORY  (BLKS) 

READ  SEGMENT  (PAGE  TABLE.LOC,  BASE  ADDR) 

L.ASTf L.INDEX]  :*  BASE. ADDR 
FI 

ELSE 

IF  NOT  IN  GLOBAL  MEMORY  THEN 
UPDATE  MHO 
UPDATE  L  AST 
RETURN 

ELSE 

ALLOCATE.GLOBAL.HEMORY  (BLKS) 

IF  IN  LOCAL  MEMORY  THEN 

MOYE  TO  GLOBAL  (L.INDEX,  BASE_ADDR,  SIZE) 

ELSE 

SIGNAL .OTHER. HEMQRY.NANAGERS (INDEX, BASE_ADDR) 
FI 
FI 
FI 

UPDATE  MMU  IMAGE  (DBR  #,  SEG  #,BASE  ADDR, ACCESS, BLKS) 
UPDATE~L  AST  ACCESS  (L  INDEX, ACCESS, DBR. # ) 
SUCCESS.CODE~: *  SIAPPED.IN 
END  SWAP. IN 


Figure  25:  Swap.ln  Pseudo-code 


6.  5142  4  5422221  °3i 

SBAP_OUT  is  invoked  when  a  user  desires  to  aove  a  seg¬ 
ment  out  of  core.  &  segment  is  swapped  out  of  core  by  ob- 
taining  its  secondary  storage  location*  writing  the  segaent 
to  that  location  (if  required) ,  and  deallocating  the  aain 
memory  used.  The  decision  to  write  the  segment  is  deter¬ 
mined  by  the  G_AST  written  bit.  This  bit  is  set  whenever  the 
segment  has  been  modified.  The  segaent  to  be  swapped  out 
can  be  in  one  of  two  states:  the  segaent  can  be  in  local 
memory,  or  the  segment  can  be  in  global  aeaory. 

If  one  process  has  the  segment  in  local  aeaory  and  the 
written  bit  is  set*  the  segaent  is  written  into  secondary 
storage  and  the  local  memory  is  deallocated.  If  the  written 
bit  is  not  set*  the  local  aeaory  need  only  be  deallocated. 
If  more  than  one  process  has  the  segaent  in  the  sane  local 
memory*  the  segaent  remains  in  core.  The  appropriate  HHU  im¬ 
age  is  updated  to  reflect  the  segments  deletion  and  the 
G_AST  No_Active_ln_Meaory  field  is  decremented. 

All  segments  in  global  aeaory  are  shared  and  writable. 
If  a  process  requests  the  segaent  to  be  swapped  out*  the 
segment  renains  in  memory.  The  BHO  image  is  updated  to  re¬ 
flect  the  segment's  deletion*  and  the  G_AST 
No_Active_In_Benory  field  is  decremented.  If  the 
No_Active_In_Beaory  indicates  that  one  process  has  the  seg¬ 
ment  in  core*  its  aeaory  manager  is  signalled  to  move  the 
segaent  to  local  memory. 
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The  pseudo-code  for  S»1P_OOT  PROCEDURE  is  presented  in 


Figure  26.  The  arguaents  passed  to  SBAP_OUT  are  the  DBB_# 
of  the  signalling  process ,  and  the  G_AST_IN DEX  of  the  seg- 
aent  to  be  reaoved.  The  return  paraaeter  is  a  success  code. 
SWiP_OOT  removes  the  segaent  froa  the  process's  virtual 
core,  deletes  the  segaent  froa  its  HHU  iaage,  and  decreaents 
the  No_4cti ve_In_8eaory  field.  If  the  segaent  can  be  reaoved 
froa  aeaory,  it  is  deterained  which  aeaory  can  be  deallocat¬ 
ed.  If  the  segaent  has  been  aodified,  it  is  written  bach  to 
secondary  storage  and  the  appropriate  aeaory  deallocated. 
If  the  segaent  has  not  been  aodified,  the  appropriate  aeaory 
is  deallocated.  If  after  the  deletion  one  process  has  the 
segaent  in  global  aeaory,  its  aeaory  aanager  need  only  be 
signalled  to  aove  the  segaent  to  local  aeaory.  when 
SWAP_0UT  successfully  coapletes,  it  returns  a  success  code 
of  "swapped  out". 
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SWAP  OUT  PROCEDURE  (DBR  •  BITE,  INDEX  WORD) 

RETURNS  (SUCCESS .CODE  BITE) 

ENTRI 

BLKS  :»  G_AST[  INDEX  ]. SIZE  /  BLK.SIZE 
FREE  PROCES  S  LIN  EAR  CORE  (BLKS) 

DELETE  NMU  ENTRI  (DBR.#,  SEG  *) 

G_AST[  INDEX ]. NO.SEGMEMTS.IN.NEHORI  -»  1 

i  Deteraine  if  segaent  has  been  written  into  ! 

IF  MMU_IMAG£(  DBR_#  ].  SDR£  SEG.i  ].  ATTRIBUTES3 WRITTEN  THEN 
!  if  segaent  has  been  written  into,  update  G  AST  ! 
SAST[  INDEX]. FLAG_BITS  :*  WRITTEN 
FI 

!  Deteraine  if  segaent  is  in  global  aeaory  I 
IF  G  ASTCINDBX].  GLOBAL  ADDR  <>  NOLL  THEN 

IF  G  AST[  INDEX  ].  NO.SEGMEHTS.IN.MEMOBI  *  0 
ANDIF  G  ASTf INDEX]. FLAG  BITS  *  WRITTEN  THEN 
WRITE  SEG  (PAGE.TABLE.LOC,  HEMORI  .ADDR) 

free.local.bit.map  (h!hori_addr,blks) 

ELSE 

IF  G  AST[ INDEX  ].NO  ACTIVE  IN  HEMORI  =  0  THEN 
FREE  LOCAL  BIT~NAP  (HEMORI  ADDR, BLKS) 

FI 

FI 

ELSE  i  If  not  in  global  aeaory  1 

IF  G  ASTCINDBX].  NO  ACTIVE  IN.HEMORI  *  0 
ANDIF  G  AST[ INDEX]. FLAG .BITS  *  WRITTEN  THEN 
WRITE  SEG  (PAGE  TABLE  LOC,  GLOBAL.ADDR) 

FREE  GLOBAL.BIT.HAP  (GLOBAL.ADDR,  BLKS) 

ELSE 

IF  G  ASTCINDEX  ].NO  ACTIVE.IN.MEMORI  *  0  THEN 
FBEE.GLOBAL.BIT.MAP  (GLOBAL.ADDR,  BLKS) 

FI 

FI 

FI 

SUCCESS  CODE  :*  SWAPPED.OUT 
END  SWAP'OUT 


Figure  26:  Swap. Out  Pseudo-code 
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I  7.  Baaciiials  U1  iiaiaais 

DEACTI? ATE_&LL  is  invoked  when  it  becoees  necessary  to 

reaove  a  segaent  froa  every  process*  address  space.  Each 
process  is  checked  to  deteraine  if  the  segaent  is  active.  If 
a  process  has  the  segaent  active,  it  is  deactivated  froa  its 
address  space.  The  pseudo  code  for  Deactivate_all  is  illus¬ 
trated  in  Figure  27.  The  paraaeters  passed  to  Deacti- 
vate.all  ace  the  deactivated  segaent* s  S.ASI  index  and  the 
L_1ST  index.  The  L.1ST  is  searched  by  DBfi_t  to  deteraine 
which  process  has  the  segaent  active.  If  the  check  reveals 
that  the  segaent  is  active,  it  is  deactivated  by  calling 
Deactivate.  If  the  segaent  was  successfully  deactivated  froa 
all  processes,  a  success_code  of  valid  is  returned. 
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DEACTIVATE  ILL  PROCEDURE  (INDEX  HQSD,  L_INDEX  WORD) 
RETURNS  (SOCCESS_CODE  SITE) 

ENTRT 

local  i  arrs 

I  :*  0 
DO 

IF  Is  BAX  DBS  *  THEN 
EXIT 
FI 

IP  L_AST[  LJENDBX].  SEGBENT_NO/ACCESS^AOTH£  I  J 
Z EE 0  THE H 

SUCCESS  CODE  :  =  DEACTIVATE  (I,  INDEX) 

IF  SOCCESS.CODE  <>  SBG_DEACTI?ATED  THEN 
RETURN 
FI 
FI 

I  ♦»  1 
OD 

SUCCESS..  CODE  :*  VALID 
END  DEACTIVATE" ALL 


Figure  27:  Deactivate  All  Pseudo-code 

s.  Bass  %  Ssai aai  to  sisizU  ssiasi 

MOVE_ro ^GLOBAL  is  invoked  when  it  becomes  necessary  to 
move  a  segaent  froa  local  to  global  aeaory.  If  a  segment  re¬ 
sides  is  one  or  more  local  aeaories,  and  a  process  with 
write  access  swaps  that  segaent  into  core,  or  if  a  segaent 
resides  in  in  local  aeaory  (with  write  access)  and  another 
process  with  read  access  requests  the  segaent  swapped  in, 
the  segaeot  is  moved  from  a  local  to  global  memory  to  avoid 
a  secondary  storage  access.  If  the  segaent  resides  in  the 
running  aeaory  manager’s  local  aeaory,  it  will  affect  the 
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segment  transfer,  otherwise  it  will  signal  another  seeory 
■anager  of  a  connected  processor  to  affect  the  transfer. 
Figure  28  illustrates  the  pseudo-code  for  HOVE_TO_GLOBAL. 
Once  the  segaent  has  been  aoved  to  global  aeaory,  the  sig¬ 
nalled  aeaory  aanager  will  update  the  HHU  iaages  for  all 
connected  processes,  and  deallocate  the  freed  local  aeaory. 
A  success  code  of  coapleted  will  be  returned  to  the  signall¬ 
ing  aeaory  aanager.  The  paraaeters  passed  to  the  aeaory 
aanager  are  the  segaent' s  L_AST  index  the  global  aeaory  ad¬ 
dress  of  the  nove,  and  the  size  of  the  segaent.  This  infor- 
aation  is  passed  because  the  G_AST  is  locked  during  this  re¬ 
guest. 


HOYS  TO  GLOBAL  PROCEDURE  ( L_I NDEX  HOED,  GLOBAL  ADDS  WORD, 

SIZE  WORD) 

RETURNS  (SUCCESS  CODS  BYTE) 

ENTRY 

1  Howe  segaent  froa  local  aeaory  to  global  aeaory  ! 

DO  HENORY  HOVE  (HEHORY_ADDfi,  GLOBAL.ADDR) 

L_AST[  INDEX ]. HEMORY_ADDR  :=  AVAILABLE 
!  Update  the  HHU  inage  to  reflect  new  address  ! 

DO  POR_ALL  DBR'S 

IP  L  AST[L  INDEX]. SEGMENT  NO/ACCESS.AUTH  <>  0  ANDIP 
HHU  I HAGE[ DBR  #  ]. SDR[ SEG_# ] . ATTRIBUTES»IN_LOCAL  THEN 
hhu  ihage[d!r  #  ].SDR[  SEG_#  ].BASE_ADDR:*GLOBAL_ADDR 
PI 
OD 

SUCCESS  CODE  VALID 
END  NOVE  TO~GLOBAL 


Figure  28:  Hove  To  Global  Pseudo-code 
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*•  asxt  a  aum  £s  iasil  auuz 

30ys_?0_LOCAL  is  inwehed  when  it  become*  necessary  to 
sow*  a  segaent  fro*  global  to  local  aesory.  fill*  occurs  when 
on*  of  two  processes  which  hold  a  s*g**at  in  global  aeaory 
swaps  th*  s«g**at  oat.  fh*  s*g**at  is  *ov*d  fro*  global  a«- 
aory  to  tha  local  aeaory  of  ths  cssaining  pcocass.  Figort  29 
illastratas  tha  pseudo-cod*  for  BOFB..TO  .LOCAL.  fh*  pars ma¬ 
ters  passad  to  th*  aeaory  aanagar  ar*  th*  s*gs*nt*s  L.AST 
index#  tha  global  address  of  ths  ji agaaot,  and  th*  six*  of 
tha  segaent.  fha  return  parameter  is  a  success  cod*.  Th* 
aau  iaages  of  tha  signalled  process  ar*  updated  after  the 
sow*  has  bean  aade#  and  tha  global  a*aory  is  deallocated. 


ROVE.TO.LOCAL  PROCEDURE  (L.ISDEZ  WORD#  GLOBAL  ADDB  WORD# 

SIZE  WORD) 

5  STORKS  (SUCCESS.CODB  BITE) 

BKTHI 

BLKS  S»  SIZE  /  BLX  SIZE 

3ASS_ADDRESS  :»  AliOCATE.LOCALJIBaDfir  (BLKS) 

!  sow*  fros  global  to  local  aesory  I 

KBBOBr.aOVE  (GLOBAL.ADDB,  BASE.ADDRESS#  SIZE) 

L.ASTt  L.IBDB1 ], BSBOBT.  ADDB  :«  BASS  ADDRESS 
DO  FOB_ALL_DBR»S 

IF  LASTtL.IKDEZ  ]. SSDEEET  K0/ACCS55  ADT9  <>  0  AM DIF 
SHO_IBAGE( DBR_#  ]. SDS[ SEG  t], ATTRIBUTES* IM  LOCAL  TREK 
aaU.IBAGBC  DBS  J>3.SDR(SEG_#1.  BASE  ADDS  j*BASE  ADDRESS 
FI 
OD 

SUCCESS  ..CODE  :*  VALID 
SRD  aovs  TO.LOCAL 


Figure  29:  Sow*  To  Local  Pseudo-code 
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io.  sbU&i  iki  us  luai 

UPDATE  is  invoiced  following  a  BOVE.TO.GLOB AL  operation. 
After  a  sagaant  has  been  aowed  froa  local  aeaory  to  global 
aeaory,  it  is  necessary  to  signal  the  aeaory  aanagars  of  all 
conaactad  processors  to  apdata  thair  as a  iaagas  and  L.AST 
with  tha  currant  location  of  tha  sagaant.  They  aust  also 
daallocata  tha  aoved  sagaant* s  local  aeaory.  Figura  30  il- 
lustratas  tha  pseudo-code  of  UPDATE.  Tha  paraaatars  passad 
to  tha  aeaory  aanagar  ara  tha  sagaant's  L.AST  index,  tha  naw 
global  addr ass  for  tha  sagaant,  and  tha  siza  of  tha  sagaant. 
Tha  return  paraaeter  is  a  success  coda. 


UPDATE  PROCEDURE  (L  IHDBX  BORD,  GLOBAL.ADDR  WORD, 

SIZE  BORD) 

RETURHS  (SUCCESS  CODE  BITE) 

EHTRT 

DO  FOB.ALL_DBB*$ 

IF  L  AST[ L  INDEX ].SEGHENT_MO/ACCESS.AUTH  <>  0  AMDIF 
BHU.I HAGEC  DBR_# ]. SDRC  SEG_# ] . ATTRIBU TBS  * IH .LOCAL  THER 
9BU.IB  AGE(  DBR.t  ].  SDR(  SEG_*  ].  BASB.ADDB  :  - 

GLOBAL  ADDR 
FI 
OD 

BLK5  :*  SIZE  /  BLK.SIZE 

FREE  LOCAL  BIT  BAP  (BEBORT.ADDR , BLES) 

L.ASTf L.IHDEX ].  SERORY.ADDR  !■  ACTIVE 
SUCCESS .CODE  S«  VALID 
BHD  UPDATE 


Figure  30:  Update  Psaudo-coda 
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E.  52M&SX 


la  this  chapter  the  detailed  design  of  the  aeaory  aanag- 
er  process  has  been  presented.  The  purpose  of  the  aeaory 
eanager  was  outlined,  followed  by  a  detailed  discussion  of 
the  seaory  eanager *s  data  bases.  The  design  presented  has 
identified  ten  basic  functions  for  the  seaory  eanager.  The 
success  codes  returned  by  the  seaory  aanager  are  presented 
in  Figure  31. 

This  design  has  assuaed  that  the  kernel  level  inter-pro¬ 
cess  synchronization  priaitives  will  be  Seltzer's  signal  and 
wait  priaitives  [14],  This  fact  doainated  the  design  deci¬ 
sion  to  lock  the  G_AST  in  the  user's  process  before  it  sig¬ 
nals  the  aeaory  aanager.  In  a  aulti-processor  enviroaaent, 
the  possibility  of  a  deadly  enbrace  exists  if  the  aeaory 
aanager  processes  lock  the  G_AST.  Should  follow  on  work  ia- 
plesent  eventcounts  and  seguencers  as  kernel  level  synchron¬ 
ization  priaitives,  the  locking  of  the  G^AST  and  aeaory  aan- 
ager  synchronization  will  need  to  be  readdressed. 
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SYSTEM  HIDE 


KEBHEL  LOCAL 


INVALID 
SWAPPED.IN 
SH APPED.OUT 
SE6  ACTIVATED 

segIdeactivated 

SEG  CHEATED 
SEG~DELETED 
VIBTOAL  COHE  POLL 
DOPLICATE.ENTRY 
READ  ERRoi 
HRITEJBRROR 
DRIVE  NOT  READ! 


LEAP_SEGMENT_EXISTS 

no  lIaf.ezists 

ALIAS  DOES  NOT. EXIST 
NO  CHILD  TO  DELETE 
G_AST_FULL 
L  AST  POLL 
LOCAL  MEMORY.PULL 
GLOBAL  MEMORY  .FULL 
SECONdIrY  STORAGE  FULL 


MEMORY  MANAGER  LOCAL 

VALID 
INVALID 
POUND 
NOTJPOOND 
IN  LOCAL  MEMORY 
NOT  IN  LOCAL  MEMORY 
!  ♦  DISK  ERRORS  ! 


Figure  31:  Success  codes 
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Chapter  XII 
ST ITUS  OP  RESEARCH 


A.  CQ8QL25IQS5 

The  memory  manager  design  utilized  state  of  the  art 
software  techniques  and  hardware  devices.  The  design  was  de¬ 
veloped  based  upon  ZILOG*S  Z8001  sixteen  bit  segmented  mi¬ 
croprocessor  used  in  conjunction  rith  the  28010  Memory  Man¬ 
agement  Unit  C  23].  k  microprocessor  which  supports 
segmentation  is  required  to  provide  access  control  of  the 
stored  data.  The  actual  implementation  of  the  selected 
thread  was  conducted  upon  the  2800 2  non-segmented  micropro¬ 
cessor  without  the  zsoio  aao. 

Hhile  information  security  requires  that  the  micropro¬ 
cessor  support  segmentation#  the  memory  manager  was  devel¬ 
oped  to  be  configuration  independent.  The  design  will  sup¬ 
port  a  multi-processor  environment#  and  can  be  easily 
implemented  upon  any  microprocessor  or  secondary  storage 
device.  The  loop  free  modular  design  facilitates  any  re¬ 
quired  expansion  or  modification. 

Global  bus  contention  is  minimized  by  the  memory  manag¬ 
er.  Segments  are  stored  in  global  aeaory  only  if  they  are 
shared  and  writable.  Secondary  storage  is  accessed  only  if 
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the  segaent  does  not  currently  reside  in  global  aeaory  or 
soae  local  aeaory.  The  controlled  sharing  of  segaents  optia- 
izes  aain  aeaory  usage. 

The  storage  of  the  alias  tables  in  secondary  storage 
supports  the  recreation  of  user  file  hierarchies  following  a 
systea  crash.  The  aliasing  scheae  used  to  address  s  :gaents 
supports  systea  security  by  not  allowing  the  segaent* s  aeao- 
ry  location  or  unique  identification  to  leave  the  aeaory 
aanager. 

The  design  of  the  distributed  kernel  was  clarified  by 
assigning  the  HSU  iaage  aanageaent  to  the  aeaory  aanager. 
The  transfer  of  responsibility  for  aeaory  allocation  and 
deallocation  froa  the  supervisor  to  the  aeaory  aanager  pro¬ 
vides  support  for  dynaaic  aeaory  aanageaent. 

In  conclusion,  the  aeaory  aanager  process  will  securely 
aanage  segaents  in  a  aulti-processor  envirouaent.  The  pro¬ 
cess  is  efficient,  and  is  configuration  independent.  The 
priaitives  provided  by  the  aeaory  aanager  will  support  the 
construction  of  any  desired  supervisor/user  process  built 
upon  the  kernel. 
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b.  KJ.WS  oi  iQM 


There  are  several  possible  areas  in  the  SASS  design  that 
can  be  looked  into  for  continued  research.  The  coaplete  ia- 
pleaentation  of  the  aeaory  aanager  design  (refine  and  optia- 
ize  the  current  PLZ/STS  code)  is  one  possibility.  Other  pos¬ 
sibilities  include  the  iapleaentation  of  dynaaic  aeaory 
aanageaent,  and  aodifying  the  interface  of  the  aeaory  aanag¬ 
er  with  the  distributed  kernel  using  eventcounts  and  se¬ 
quencers  for  inter-process  coaaunication. 

The  iapleaentation  of  the  supervisor  has  not  been  ad¬ 
dressed  to  date.  Areas  of  research  include  the  inplaenta- 
tion  of  the  file  aanager  and  input/output  processes,  and  the 
coaplete  design  and  iapleaentation  of  the  user-host  proto¬ 
cols.  The  iapleaentation  of  the  gatekeeper,  and  systea  ini¬ 
tialization  are  other  possible  research  areas.  Dynaaic  pro¬ 
cess  creation  and  deletion,  and  the  introduction  of 
aulti-level  hosts  could  also  prove  interesting. 
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PART  0 

AN  IMPLEMENTATION  OP  MULTIPROGRAMMING  BHD 
PBOCESS  MANAGEMENT  FOB  A  SECURITI  KERNEL 
OPEBATIHG  SIS TEH 


This  section  contains  updated  excerpts  £roa  a  Naval  Post¬ 
graduate  School  MS  Thesis  by  S.  L.  Seitz  £12].  The  origins 
of  these  excerpts  are: 

INTRODUCTION  froa  Chapter  I 
IMPLEMENTATION  froa  Chapter  IV 
CONCLUSION  froa  chapter  V 

Minor  changes  have  been  Bade  for  integration  into  this  report. 


Chapter  XIII 
IiTHODOCTIOB 

The  application  of  conteaporary  microprocessor  technolo¬ 
gy  to  the  design  of  large-scale  eultiple  processor  systeas 
offers  many  potential  benefits.  The  cost  of  high-power  com¬ 
puter  systeas  could  be  reduced  drastically;  fault  tolerance 
in  critical  real-tiae  systeas  could  be  improved;  and  compu¬ 
ter  services  could  be  applied  in  areas  where  their  use  is 
not  now  cost  effective.  Designing  such  systeas  presents 
many  formidable  problems  that  have  not  been  solved  by  the 
specialized  single  processor  systeas  available  today. 

Specifically,  there  is  an  increasing  demand  for  computer 
systeas  that  provide  protected  storage  and  controlled  access 
for  sensitive  information  to  be  shared  among  a  wide  range  of 
users.  Data  controlled  by  the  Privacy  ict,  classified  De¬ 
partment  of  Defence  (DoD)  information,  and  the  transactions 
of  financial  institutions  are  but  a  few  of  the  areas  which 
require  protection  for  multiple  levels  of  sensitive  informa¬ 
tion.  Multiple  processor  systeas  which  share  data  are  well 
suited  to  providing  such  services  -  if  the  data  security 
problem  can  be  solved. 

K  solution  to  these  problems  -  a  multiprocessor  systea 
design  with  verifiable  inforaation  security  -  is  offered  in 
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a  family  of  secure,  distributed  aulti-eicroprocessor  operat¬ 
ing  systeas  designed  by  O'Connell  and  Bichardson  [7].  A 
subset  of  this  faaily,  the  Secure  Archival  Storage  Systea 
(SASS)  [9,5],  has  been  selected  as  a  testbed  for  the  general 
design.  SASS  will  provide  consolidated  file  storage  for  a 
network  of  possibly  dissiailar  "host4*  computers.  The  systea 
will  provide  controlled,  shared  access  to  multiple  levels  of 
sensitive  inforaation  (Figure  32) . 

This  thesis  presents  an  iapleaentation  of  a  basic  moni- 
tor  for  the  O' Connell-Bichardson  faaily  of  operating  sys¬ 
tems.  The  aonitor  provides  aultiprograaaing  and  process 
management  functions  specifically  addressed  to  the  control 
of  physical  processor  resources  of  SASS.  Concurrent  thesis 
work  [7]  is  developing  a  detailed  design  for  a  security  ker¬ 
nel  process,  the  Meaory  Manager,  which  will  aanage  SASS  ae- 
aory  resources. 
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Chapter  XIV 
IHPIEHEHTATIOI 

lapleaentation  of  the  distributed  kernel  was  siaplified 
by  the  hierarchical  structure  of  the  design  for  it  perait- 
ted  aethodical  botton-up  construction  of  a  series  of  extend¬ 
ed  nachines.  This  approach  was  particularly  useful  in  this 
inpleaentation  since  the  bare  aachine,  the  Z8000  Developaen- 
tal  Sodule,  was  provided  with  only  a  saall  aaount  of  soft¬ 
ware  support. 

A.  Q2I£L2£fl£BXHt  SOPPOax 

k  Zilog  HCZ  Developaeatal  Systea  provided  support  in  de¬ 
veloping  Z8000  aachine  code.  It  provided  floppy  disk  file 
aanageaent,  a  text  editor,  a  linker  and  a  loader  that  creat¬ 
ed  an  inage  of  each  Z8000  load  aodule. 

k  Z8000  Developaental  nodule  (OH)  provided  the  necessary 
hardware  support  for  operation  of  a  Z8002  non-segaented  ai- 
croprocessor  and  16K  words  (32K  bytes)  of  dynaaic  BAH.  It 
included  a  clock,  a  USAB7,  serial  and  parallel  I/O  support, 
and  a  2K  PBOH  aonitor. 

The  aonitor  provided  access  to  processor  registers  and 
neaory,  single  step  and  break  point  functions,  basic  I/O 
functions,  and  a  download/upload  capability  with  the  HCZ 
systea. 
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Sines  a  sag.ented  version  of  Ut  processor  ...  00t 
a.ailabU  tor  sjrst.a  iav.lopa.at.  segaentation  hariv.r. 
siaolated  u  softvar.  as  an  sag  iaag.  fi^t,  _  Ut_ 

hongl,  this  data  strnctar.  did  not  provid.  ta.  h.rd.ar.  snp- 
port  (trapsi  tegnir.d  to  protect  segaants  of  to.  kernel  do- 
aain,  it  preserved  the  general  structure  of  the  design. 
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Figure  33:  SHU^IHAGB 
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B.  IIUB  ISA £U£  ££1X£0U£1 

The  Inner  Traffic  Controller  runs  on  the  bare  aachine  to 
create  a  virtual  environment  for  the  resainder  of  the  sys- 
tee.  Only  this  eodule  is  dependent  on  the  physical  proces¬ 
sor  configuration  of  the  systee.  All  higher  levels  see  only 
a  set  of  running  virtual  processors.  A  kernel  data  base, 
the  Virtual  Processor  Table  is  used  by  the  Inner  Traffic 
Controller  to  create  the  virtual  environeent  of  this  first 
level  extended  aachine.  A  source  listing  of  the  Inner 
Traffic  Controller  aodule  is  contained  in  Appendix  G. 

1*  EC2SS332I  Xl&lfi  (IK) 

The  VPT  is  a  data  structure  of  arrays  and  records  that 

maintains  the  data  used  by  the  Inner  Traffic  Controller  to 
aultiplex  virtual  processors  on  a  real  processor  and  to 
create  the  extended  instruction  set  that  controls  virtual 
processor  operation  (see  Figure  34) .  There  is  one  table  for 
each  physical  processor  in  the  system.  Since  this  implemen¬ 
tation  was  for  a  uniprocessor  system  (the  Z8000  DHJ  ,  only 
one  table  was  necessary. 

The  table  contains  a  LOCK  which  supports  an  exclusion 
mechanism  for  a  multiprocessor  system.  It  was  provided  in 
this  implementation  only  to  preserve  the  generality  of  the 
design. 

The  Descriptor  Base  Register  (DBfi)  binds  a  process  to  a 
virtual  processor.  The  DBR  points  to  an  RBtJ_IHAGE  contain- 
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BOUNINS  LIST 
READT_LIST 
FREE  LIST 


VP  |DBB|  PR I |  STATE!  IDLE  FLAG |  CPU!  NEXT  VPJ  8SG  LIST| 
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Figure  34:  Virtual  Processor  Table 


ing  the  list  of  descriptors  for  segaeats  iu  the  process  ad¬ 
dress  space. 

A  virtual  processor  (VP)  can  be  ia  one  of  three  states: 
running,  ready,  and  waiting  (Figure  35) .  A  running  VP  is 
currently  scheduled  on  a  real  processor.  A  ready  VP  is 
ready  to  be  scheduled  when  selected  by  the  level- 1  schedul- 


ing  algorithm,  h  waiting  VP  is  awaiting  a  message  from  some 


other  VP  to  place  it  in  the  ready  list.  In  the  meantime  it 
is  not  in  contention  for  the  real  processor. 


2.  isisizi  sshadaliM 

Tirtual  processor  state  changes  are  initiated  by  the  in¬ 
ter-virtual-processor  coeeunication  mechanisms,  SIGNAL  and 
BAIT*  These  level**  1  instructions  iepleeent  the  scheduling 
policy  by  ieteraining  what  virtual  processor  to  bind  to  the 
real  processor.  The  actual  binding  and  unbinding  is  per- 
forced  by  a  Processor  switching  mechanise  called  StfAP_DBB 
[14].  Processor  switching  implies  that  somehow  the  execu¬ 
tion  point  end  address  space  of  a  new  process  are  acquired 
by  the  processor.  Care  must  be  taken  to  ^isure  that  the  old 
process  is  saved  and  the  new  process  loaded  in  an  orderly 
manner.  A  solution  to  this  problem,  suggested  by  Saltzer 
[14],  is  to  design  the  switching  mechanism  so  that  it  is  a 
common  procedure  having  the  same  segment  number  in  every  ad¬ 
dress  space. 

In  thi3  implementation  a  processor  register  (B14)  was 
reserved  within  the  switching  mechanism  for  use  as  a  DBS. 
Processor  switching  was  performed  by  saving  the  old  execu¬ 
tion  point  (  i.e.,  processor  registers  and  flag  control 
word) ,  loading  the  new  DBB  and  then  loading  the  new  execu¬ 
tion  point.  The  processor  switch  occurs  at  the  instant  the 
DBB  is  changed  (see  Figure  36) .  Because  the  switching 
procedure  is  distributed  in  the  same  numbered  segment  in  all 
address  spaces,  the  "next"  instruction  at  the  instant  of  the 
switch  will  have  the  same  offset  no  matter  what  address 
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space  the  processor  is  in.  This  is  the  hey  to  the  proper 
operation  of  SHAP_DBH. 

To  convert  this  switching  eechanise  to  segaented  hard¬ 
ware  it  is  necessary  eerely  to  replace  SiiP_DBB  with  special 
I/O  block-aove  instructions  that  save  the  contents  of  the 
nno  in  the  appropriate  SHU_IHAGE  and  load  the  contents  of 
the  new  aHU_IHAGE  into  the  HMD. 

a.  Getwork 

s»AP_DBH  is  contained  within  an  internal  Inner  Traffic 
Controller  procedure  called  GETMOBK.  In  addition  to  aulti- 
plezing  virtual  processors  on  the  CPU,  GET  WORK  interprets 
the  virtual  processor  status  flags,  IDLE  and  Pfi EEMPT ,  and 
aodifies  VP  scheduling  accordingly  in  an  atteapt  to  keep  the 
CPU  busy  doing  useful  work. 

There  are  actually  two  classes  of  idle  processes  within 
the  systea.  One  class  belongs  to  the  Traffic  controller. 
Conceptually  there  is  a  ready  level-2  idle  process  for  each 
virtual  processor  available  to  the  Traffic  Controller  for 
scheduling.  ffhen  a  running  process  blocks  itself,  the 
Traffic  Controller  schedules  the  first  ready  process.  This 
will  be  an  idle  process  if  no  supervisor  processes  are  in 
the  ready  list. 

The  second  class  of  idle  process  exists  in  the  kernel. 
The  kernel  Idle  process  is  persanently  bound  to  the  lowest 
priority  virtual  processor. 
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Figure  36:  SiAP_DBB 
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The  distinction  is  made  between  these  classes  because  of 
the  need  to  keep  the  CPU  busy  doing  useful  work  whenever 
possible.  There  is  no  need  for  GETWORK  to  schedule  a  lev¬ 
el-2  idle  process  that  has  been  loaded  on  a  virtual  proces¬ 
sor,  because  the  idle  process  does  no  useful  work.  The  vir¬ 
tual  processor  IDLE_FLAG  indicates  that  a  virtual  processor 
has  been  loaded  with  a  level-2  idle  process.  GETWORK  will 
schedule  this  virtual  processor  only  if  the  PBEEflPT  flag  is 
also  set.  The  PREEHPT  flag  is  a  signal  from  the  Traffic 
Controller  that  a  supervisor  process  is  now  ready  to  run. 

When  GETWORK  can  find  no  other  ready  virtual  processors 
with  IDLE  and  PREEMPT  flags  off,  it  will  select  the  virtual 
processor  permanently  bound  to  the  kernel  Idle  process. 
Only  then  will  the  Idle  process  actually  run  on  the  CPU. 

Getwork  contains  two  entry  points.  The  first,  a  normal 
entry,  resets  the  preempt  interrupt  return  flag.  (RQ  is  re¬ 
served  for  this  purpose  within  GETWO&K.)  The  second,  a 
hardware  interrupt  entry  point,  contains  an  interrupt  han¬ 
dler  which  sets  the  preempt  interrupt  return  flag.  The  DBR 
(R 14)  must  also  be  set  to  the  current  value  by  any  procedure 
that  calls  GETWORK  in  order  to  permit  the  SWAP_DBR  portion 
of  GETWORK  to  have  access  to  the  scheduled  process's  address 
space.  Upon  completion  of  the  processor  switch,  GETWOBK  ex¬ 
amines  the  interrupt  return  flag  to  determine  whether  a  nor¬ 
aal  return  or  an  interrupt  return  is  required. 
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The  hardware  interrupt  entry  point  in  GETHOBK  supports 
the  technique  used  to  initialize  the  systea.  Each  process 
address  space  contains  a  kernel  doeain  stack  segment  used  by 
SHAP-DBB  in  GETHORK  to  save  and  restore  VP  states.  For  the 
saae  reason  that  SHAP-DBB  is  contained  in  a  systea  wide  seg- 
aent  nuaber ,  the  stack  segaent  in  each  process  address  space 
will  also  have  the  saae  nuaber  (Segaent  #1  in  this  iapleaen- 
tation) .  Each  stack  segaent  is  initially  created  as  though 
it*s  process  had  been  previously  preeapted  by  a  hardware  in¬ 
terrupt.  This  greatly  siaplifies  the  initialization  of  pro¬ 
cesses  at  systea  generation  time.  The  details  of  systea  in¬ 
itialization  will  be  described  later  in  this  chapter.  It  is 
iaportant  to  note  here,  however,  that  GETHOBK  aust  be  able 
to  deteraine  whether  it  was  invoked  by  a  hardware  preeapt 
interrupt  or  by  a  noraal  call,  before  it  can  execute  a  re¬ 
turn  to  the  calling  procedure.  This  is  because  a  hardware 
interrupt  causes  three  iteas  to  be  placed  on  the  systea 
stack:  the  return  location  of  the  caller,  the  flag  control 
word,  and  the  interrupt  identifier,  whereas  a  noraal  call 
places  only  the  return  location  on  the  stack.  Therefore,  in 
order  to  clean  up  the  stack,  GETHOBK  aust  execute  an  inter¬ 
rupt  return  (assaably  instruction :IBET)  if  entry  was  via  the 
hardware  preeapt  handler  (i.e.,  BO  set).  This  instruction 
will  pop  the  three  iteas  off  the  stack  and  return  to  the  ap¬ 
propriate  location.  If  the  interrupt  return  flag,  BO,  is 
off,  a  noraal  return  is  executed. 


During  normal  operation,  SMAP-DB8  manipulates  process 
stacks  to  save  the  old  VP  state  and  load  the  new  VP  state. 


This  action  proceeds  as  follows  (Figure  37) : 

1.  The  Plag  Control  Word  (FC8) ,  the  Stack  Pointer  (815) 
and  the  preempt  return  flag  (80)  are  saved  in  the  old 
VP’s  kernel  stack. 

2.  The  DBB  (814)  is  loaded  with  the  new  VP’s  DBS.  This 
permits  access  to  the  address  space  of  the  new  pro¬ 
cess. 

3.  The  Flag  Control  Hord  (FC8),  the  Stack  Pointer  (815) 
and  the  Interrupt  Heturn  Flag  (SO) ,  are  loaded  into 
the  appropriate  CPU  registers. 

4.  80  is  tested.  If  it  is  set,  GET80RK  will  execute  an 
interrupt  return.  If  it  is  off,  a  normal  return  oc¬ 
curs. 

By  constructing  GET80BK  in  this  way,  both  systes  initializa¬ 
tion  and  normal  operations  can  be  handled  in  the  same  way. 
A  high  level  GETHORK  algorithm  is  given  in  Figure  38. 
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GETWORK  Procedure  (DBS  »  R14) 

Begin 

Beset  Interrupt  Bet urn  Flag  (BO) 

Skip  hardware  preeapt  handler 

Hardware  Preeapt  Entry: 

Set  DBB 

Save  CPU  registers 

Save  supervisor  stack  pointer 

Set  interrupt  Beturn  Flag  (BO) 

Get  first  ready  VP 

Do  while  not  select 
If  Idle  flag  is  set  then 
if  Preeapt  flag  is  set  then 
select 
else 

get  next  ready  VP 
end  if 
else 
select 
end  if 
end  do 

S«AP_DBR: 

Save  old  VP  registers  in  stack  segaent 
Swap  dbr  (B1 4) 

Load  new  VP  registers  in  stack  segaent 

If  Interrupt  Return  Flag  is  set  then 
unlock  vpt 

siaulate  GATEKEEPER  exit: 

Call  TEST.VPBEEBPT 

Restore  supervvisor  registers 

Bestore  supervvisor  stack  pointer 

Execute  Interrupt  Beturn  (IBET) 
end  if 

Execute  noraal  return 
end  GETVOBK 


Figure  38:  5ETH0BK 
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3.  xisiail  etassasag  laaimsslan  Sag 

The  heart  of  the  SASS  scheduling  mechanism  is  the  inter¬ 
nal  procedure,  GETWOBK.  It  provides  a  powerful  internal 
primitive  for  use  by  the  virtual  processors  and  greatly  sia- 
plifies  the  design  of  the  virtual  processor  instruction  set. 
Virtual  processor  instructions  perfora  three  types  of  func¬ 
tions:  aultiprograaaing,  process  aanageaent  and  virtual  in¬ 
terrupts. 

SIGNAL  and  BAIT  provide  synchronization  and  coaaunica- 
tion  between  virtual  processors.  They  multiplex  virtual 
processors  on  a  CPU  to  provide  aultiprograaaing.  This  ia- 
pleaentation  used  a  version  of  the  signal  and  wait  algor¬ 
ithms  proposed  by  Saltzer  £14],  In  the  SASS  design  each  CPU 
is  provided  with  a  unique  (fixed)  set  of  virtual  processors. 
The  interaction  among  virtual  processors  is  a  result  of  mul¬ 
tiprogramming  thea  on  the  real  processor.  Only  one  virtual 
processor  is  able  to  access  the  VPT  at  a  tine  because  of  the 
use  of  the  VPT  LOCK  (SPIN_LOCK)  to  provide  mutual  exclusion. 
Therefore  race  and  deadlock  conditions  will  not  develop  and 
the  signal  pending  switch  used  by  Saltzer  is  not  necessary. 

This  iapleaentation  also  included  message  passing  mecha¬ 
nism  not  provided  by  Saltzer.  The  aessage  slots  available 
for  use  by  virtual  processors  are  initially  contained  in  a 
queue  pointed  to  by  FBEE-LI5T.  When  a  aessage  is  sent  froa 
one  VP  to  another,  a  aessage  slot  is  removed  froa  the  free 


126 


list  and  placed  in  a  FIFO  message  queue  belonging  to  the  7? 


receiving  the  Message.  The  head  o f  each  ?P's  message  queue 
is  pointed  to  by  MSG-LIST.  Each  message  slot  contains  a 
message,  the  ID  of  the  sender,  and  a  pointer  to  the  next 
message  in  the  list  (either  the  free  list  or  the  7P  message 
list. 

IDLE  and  SWAP_VDBH  provide  the  Traffic  Controller  with  a 
means  of  scheduling  processes  on  the  running  7P. 

SET_7PaEESPT  and  TEST_VPBEEaPT  install  a  virtual  inter¬ 
rupt  mechanism  in  each  virtual  processor.  when  the  Traffic 
Controller  determines  that  a  virtual  processor  should  give 
up  its  process  because  a  higher  priority  process  is  now 
ready,  it  sets  the  PREEMPT  flag  in  that  vp.  Then,  even  if 
an  idle  process  is  loaded  on  the  7p,  it  mill  be  scheduled 
and  will  be  loaded  with  the  first  ready  process. 
Test_7Preempt  is  a  virtual  interrupt  unmasking  mechanism 
which  forces  a  process  to  examine  the  preempt  flag  each  time 
it  exists  from  the  kernel. 

a.  Bait 

BAIT  provides  a  means  for  a  virtual  processor  to  move 
itself  from  the  running  state  to  the  waiting  state  when  it 
has  no  more  work  to  do.  It  is  invoked  only  for  system 
events  that  are  always  of  short  duration.  It  is  supported 
by  three  internal  Procedures. 
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SPIN _L3CK  enables  the  running  TP  to  gain  control  of  the 
Virtual  Processor  Table.  This  procedure  is  only  necessary 
in  a  aultiprocessor  environment.  The  running  TP  will  have 
to  wait  only  a  short  aaount  of  tine  to  gain  control  of  the 
TPT.  SPIN.LOCiC  returns  when  the  TP  has  locked  the  VPT. 

GETBORK  loads  the  first  eligible  virtual  processor  of 
the  ready  list  on  the  real  processor.  Before  this  procedure 
is  invoked,  the  running  TP  is  placed  in  the  ready  state. 
Both  ready  and  running  TP's  are  neebers  of  a  FIFO  gueue. 
GETWORK  selects  the  first  TP  in  this  ready  list,  loads  it  on 
the  CPU,  and  places  it  in  the  running  state.  Bhen  GETBORK 
returns,  the  first  TP  of  the  gueue  will  always  be  running 
and  the  second  will  be  the  first  TP  in  the  ready  gueue. 

GET _FIRST_HESS  AGE  returns  the  first  eessage  of  the  mes¬ 
sage  list  (also  managed  as  a  FIFO  gueue)  associated  with  the 
running  TP.  The  action  taken  by  BAIT  is  as  follows: 

bait  Procedure  (Returns:  Hsg,  Sender.IO) 

Begin 

Lock  TPT  (call  SPIN.LOCK) 

If  message  list  empty  (i.e.,  no  work)  Then 
Hove  TP  from  Running  to  Baiting  state 
Schedule  first  eligible  Ready  TP  (call  GETBORK) 
end  if 

(NOTE:  process  suspended  here  until 
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b.  Signal 

Messages  are  passed  between  virtual  processors  by  the 
instruction,  SIGNAL,  which  uses  four  internal  procedures, 
SPIN_LOCK,  BNTER_HSG_LIST,  HAKE_B EADY,  and  GETHOEK. 

SPIN_LOCK ,  as  explained  above  insures  that  only  one  vir¬ 
tual  processor  has  control  of  the  Virtual  Processor  Table  at 
a  tiae. 

ENTEB_MSG_LIST  manages  a  FIFO  message  gueue  for  each 
virtual  Processor  and  for  free  messages.  This  gueue  is  of 
fixed  maximum  length  because  of  the  implementation  decision 
to  restrict  the  use  of  SIGNAL.  A  running  VP  can  send  no 
more  than  one  message  (SIGNAL)  before  it  receives  a  reply 
(i.e. ,  HAIT's  for  a  message).  Therefore  if  there  are  N  vir¬ 
tual  processors  per  real  processors,  the  message  gueue 
length,  L,  is: 

L  -  H  -  1 

HAKE.BEAOT  manages  the  virtual  processor  ready  gueue. 
If  a  message  is  sent  to  a  VP  in  the  waiting  state, 
HAKE.BEADT  wakes  it  up  (it  places  it  in  the  ready  state)  and 
enters  it  in  the  ready  list.  If  a  running  VP  signals  a 
waiting  VP  of  higher  priority,  it  will  place  itself  back  in 
the  ready  state  and  the  higher  priority  VP  will  be  selected. 
The  action  taken  by  signal  is  as  follows: 

SIGNAL  Procedure  (Message,  Destination_VP) 

Begin 
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Lock  VPT  (call  SPI R_LOCK) 

Send  aessage  (call  ENTBa_HSG_LISI) 

If  signaled  VP  is  waiting  Then 
Make  it  up  and  sake  it  ready 
(call  HAKE_B EADT) 
end  if 

Put  running  VP  in  ready  state. 

Schedule  first  elgible  ready  VP 
(call  GETHOBK) 

Unlock  VPT 

Return  (Success_coae) 

End  SIGNAL 

c.  SBAP.VOBB 

SHAP_VDBR  contains  the  saae  processor  switching  aechan- 
isa  used  in  SHAP_DBR#  but  applies  it  to  a  virtual  processor 
rather  than  a  real  processor.  Switching  is  quite  simple  in 
this  virtual  environment  because  both  processor  execution 
point  and  address  space  are  defined  by  the  Descriptor  Base 
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Register.  SHAP_VDBB  is  invoiced  by  the  Traffic  Controller  to 
load  a  new  process  on  a  virtual  processor  in  support  of  lev- 
el-2  scheduling.  It  uses  GET WORK  to  control  the  associated 
level-1  scheduling.  The  action  taken  by  SWAP.TDBB  is: 

SHAP.7DBB  Procedure  (Nev_DBB) 

Begin 

Lock  VPT  (call  SPIB_LOC K) 

Load  running  TP  with  New.OBB 
Place  running  TP  in  ready  state 
Schedule  first  eligible  ready  TP 
(call  G2TK0RK) 

Unlock  TPT 
Bet urn 

End  SBAPJTDBH 


In  this  iapieeentation  one  restriction  is  placed  upon 
the  use  of  this  instruction.  If  a  virtual  processor's  mes¬ 
sage  list  contains  at  least  one  aessage,  it  can  not  give  up 
its  current  DBB.  This  probles  is  avoided  as  the  natural  re¬ 
sult  of  using  SIGHAL  and  BAIT  only  for  systea  events,  and 
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"■asking"  preempts  within  the  kernel.  If  this  were  permit¬ 
ted,  the  lessages  would  lose  their  context.  (The  aessages 
in  a  vp_MS3_LIST  are  actually  intended  for  the  process  load¬ 
ed  on  the  VP.) 

d.  IDLE 

The  IDLE  instruction  loads  the  Idle  DBS  on  the  running 
virtual  processor.  Only  virtual  processors  in  contention 
for  process  scheduling  will  be  loaded  by  this  instruction. 
(The  Traffic  Controller  is  not  even  aware  of  virtual  proces¬ 
sors  peraanently  bound  to  kernel  processes.) 

IDLE  has  the  saae  scheduling  effect  as  Stf AP_VDBH,  but  it 
also  sets  the  IDLE_FLAG  on  the  scheduled  VP.  The  distinc¬ 
tion  is  aade  between  the  two  cases  because,  although  the 
Traffic  Controller  aust  schedule  an  Idle  process  on  the  VP 
if  there  are  no  other  ready  processes,  the  Inner  Traffic 
Controller  does  not  wish  to  schedule  an  Idle  VP  if  there  is 
an  alternative.  This  would  be  a  waste  of  physical  processor 
resources.  The  setting  of  the  IDLE_FLAG  by  the  Traffic 
Controller  aids  the  Inner  Traffic  Controller  in  aaking  this 
scheduling  decision.  Logically,  there  is  an  idle  process 
for  each  VP;  actually  the  saae  address  space  (DBB)  is  used 
for  all  idle  processes  for  the  saae  CPO,  since  only  one  will 
run  at  a  tiae.  As  previously  explained,  virtual  processors 
loaded  by  this  instruction  will  be  selected  by  GETHOBK  only 
to  give  the  Idle  process  away  for  a  new  process  in  response 
to  a  virtual  preeapt  interrupt.  The  action  of  IDLE  is: 
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IDLE  Procedure 


Begin 

Lock  VPT  (call  SPIH_LOCK) 

Load  running  VP  with  Idle  OBR 
set  VP's  IDLE_FLAG 
Place  running  VP  in  ready  state 
Schedule  first  elgible  ready  VP 
(call  GETHOHK) 

Unlock  VPT 
Return 
End  IDLE 


e.  SET_VPREEHPT 

SET_VPREEHPT  sets  the  press pt  interrupt  flag  on  a  speci¬ 
fied  virtual  processor.  This  forces  the  virtual  processor 
into  level- 1  scheduling  contention,  even  if  it  is  loaded 
with  an  Idle  process.  The  instruction  retrieves  an  idle 

-  134  - 


virtual  processor  in  the  sase  way  a  hardware  preespt  ret¬ 
rieves  an  idle  CPO  by  forcing  the  VP  to  be  selected  by 
GETBOBK.  The  only  difference  between  the  two  cases  is  the 
entry  point  used  in  GETWOBK.  The  action  of  SET_VPBEEEPT  is: 

SET_VPBEEHPT  Procedure  (VP) 

Begin 

Set  VP's  PBEEMPT  flag 
If  VP  belongs  to  another  CPO  Then 
send  hardware  interrupt 
end  if 
Beturn 

End  SET  VPBBEMPT 


Since  the  action  is  a  safe  sequence,  no  deadlocks  or 
race  conditions  will  arise  and  no  lock  is  required  on  the 
VPT. 

f.  TES  T_V  PH  BE  SPT 
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Within  the  kernel  of  a  multiprocessor  system  all  process 
interrupts  (which  excludes  system  I/O  interrupts)  are 
masked.  If  process  interaction  results  in  a  virtual  preempt 
being  sent  to  the  running  virtual  processor  by  another  CPU, 
it  will  not  be  handled  since  GETHOBK  has  already  been  in¬ 
voked.  TEST_V PREEMPT  provides  a  virtual  preempt  interrupt 
unmasking  mechanism. 

TEST_VPREEMPT  mimics  the  action  of  a  physical  CPU  when 
interrupts  are  unmasked.  It  forces  the  process  execution 
point  back  down  into  the  kernel  each  time  the  process  at¬ 
tempts  to  leave  the  kernel  domain,  where  the  preempt  flag  of 
the  running  VP  is  examined.  If  the  flag  is  off, 
TEST_VPREEMPT  returns  and  the  execution  point  exits  through 
the  Gatekeeper  into  the  supervisor  domain  of  the  pro 'ess  ad¬ 
dress  space  as  described  above.  However,  if  the  PREEMPT 
flag  is  on,  the  TEST_VPRESMPT  executes  a  virtual  interrupt 
handler  located  in  the  Traffic  Controller.  This  Jump  from 
the  Inner  Traffic  Controller  to  the  Traffic  Controller 
(TC_PREEMPT_H AM DLER)  is  a  close  parallel  to  the  action  of  a 
CPU  in  response  to  a  hardware  interrupt,  that  is  a  jump  to 
an  interrupt  handler.  The  Traffic  Controller  Preempt  Han¬ 
dler  forces  level-2  and  level-1  scheduling  to  proceed  in  the 
normal  manner.  The  preempt  handler  forces  the  Traffic  Cont¬ 
roller  to  examine  the  APT  and  to  apply  the  level-2  schedul¬ 
ing  algorithm,  TC_GETWOBK.  If  the  APT  has  been  changed 
since  the  last  invocation  of  this  sct.«dulsr,  it  will  be  re- 
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fleeted  la  the  scheduling  selections.  Eventually,  when  the 
running  VP's  preempt  flag  is  tested  and  found  to  be  reset, 
TEST_VPRBEMPT  will  return  to  the  Gatekeeper  where  toe  pro¬ 
cess  execution  point  will  finally  sake  a  noraal  exit  into 
its  supervisor  dosain.  TEST_VPSEEHPT  perforce  the  following 
action: 

TESTOV PREEMPT  Procedure 
Begin 

Do  while  running  VP's  PREEMPT  flag  is  set 
Reset  PREEMPT  flag 
Call  preeapt  handler 

(call  TC_PREEMPT_H ANDIES) 

End  do 
Return 

End  TESTJTPREEMPT 


c.  XSMZIC  CQBI1QLLSB 

The  Traffic  Controller  runs  in  a  virtual  environment 
created  by  the  Inner  Traffic  Controller.  It  sees  a  set  of 
running  virtual  processor  instructions:  SB1P_VDB2,  IDLE, 
SET_VPBEEaPT,  and  RtJNNIHG_VP,  and  provides  a  scheduler, 
TC_GETSORK,  which  multiplexes  processes  on  virtual  proces- 
sors  in  response  to  process  interaction.  It  also  creates  a 
level-2  instruction  set:  ADVANCE,  AWAIT,  and  PBOCE$S_CLASS, 
which  is  available  for  use  by  higher  levels  of  the  design. 
The  Traffic  Controller  uses  a  global  data  base,  the  ACTIVE 
PROCESS  TABLE  to  support  its  operation. 

4siiis  Ecassss  Xabls  (MX) 

The  Active  Process  Table  is  a  systea-wide  kernel  data¬ 
base  containing  entries  for  each  supervvisor  process  in  SASS 
(Figure  39)  .  It  is  indexed  by  active  process  ID.  The 
structure  of  the  APT  closely  parallels  that  of  the  Virtual 
Processor  Table.  It  contains  a  LOCK  to  support  the  iaple- 
aentation  of  a  autual  exclusion  nechanisa,  a  HUNNING_LIST, 
and  a  BEADY _LIST„HEAD .  The  Traffic  Controller  is  only  con¬ 
cerned  with  virtual  processors  that  can  be  loaded  with  su¬ 
pervisor  processes.  Since  two  VP's  are  permanently  bound  to 
kernel  processes  (the  Memory  Manager  and  the  Idle  Process), 


they  cannot  be  in  contention  for 

level-2 

scheduling; 

the 

Traffic  Controller 

is 

unaware  of 

their 

existence; 

since 

there  are  a  nuaber 

of 

available 

virtual 

processors. 

the 
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R0HNING_LIST  was  implemented  as  an  array  indexed  by  ?P_ID. 
The  READY_LIST_HEAD  points  to  a  PIFO  queue  that  includes 
both  running  and  ready  processes.  The  running  processes 
will  be  at  the  top  of  the  ready  list. 

Because  of  their  completely  static  nature,  idle  process¬ 
es  require  no  entries  in  the  APT.  Logically,  there  is  an 
idle  process  at  the  end  of  the  ready  list  for  each  TP  avai¬ 
lable  to  the  Traffic  Controller.  If  the  ready  list  is  eep- 
ty ,  TC_GETWOHK  loads  one  of  these  "virtual"  idle  processes 
by  calling  IDLE,  and  enters  a  reserved  identifier,  *IDL2,  in 
the  appropriate  RONNIIMG.LIST  entry.  This  identifier  is  the 
only  data  concerning  idle  processes  that  is  contained  in  the 
APT.  Idle  process  scheduling  considerations  are  moved  down 
to  level-1,  because  the  Inner  Traffic  Controller  knows  about 
physical  processors,  and  can  optimize  CPU  use  by  scheduling 
idle  processes  only  when  there  is  nothing  else  to  do. 

The  subject  access  class,  S_CLASS,  provides  eacn  process 
with  a  label  that  is  required  by  level-3  modules  to  enforce, 
the  SASS  non-discret ionary  security  policy. 
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Figure  39:  Active  Process  Table 


2.  hanizi  Sstedaliflg 

Above  the  Traffic  Controller,  SASS  appears  as  a  collec¬ 
tion  of  processes  in  one  of  the  three  states:  running, 
ready,  or  blocked.  Sunning  and  ready  states  are  analogous 
to  the  corresponding  virtual  processor  states  of  the  Inner 
Traffic  Controller.  However,  because  of  the  use  of  event- 
count  synchronization  aechanisss  by  the  Traffic  Controller, 
the  blocked  state  has  a  slightly  different  connotation  than 
the  VP  waiting  state. 

Blocked  processes  are  waiting  for  the  occurrence  of  a 
non-systea  event,  e.g. ,  the  event  occurrence  nay  be  sig¬ 
nalled  from  the  supervisor  donain.  When  a  specific  event 
happens,  all  of  the  blocked  processes  that  were  awaiting 
that  event  are  awakened  and  placed  in  the  ready  state.  This 
broadcast  feature  of  event  occurrence  is  note  powerful  than 
the  message  passing  aechanisn  of  SIGNAL,  which  aust  be  di¬ 
rected  at  a  single  recipient. 

Just  as  SIGNAL  and  WAIT  provide  virtual  processor  nulti- 
plixing  in  level-1,  the  eventcount  functions,  ADVANCE  and 
AWAIT,  control  process  scheduling  in  level-2. 

a.  TC_GETWOHK 

Le7el-2  scheduling  is  inpleaented  in  the  internal  Traff¬ 
ic  Controller  procedure,  TC_GET HO RK .  This  procedure  is  in¬ 
voked  by  eventcount  functions  when  a  process  state  change 
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aay  have  occurred.  It  loads  the  first  ready  process  on  the 
currently  scheduled  VP  (i.e.,  the  virtual  processor  that  has 
been  scheduled  at  level' 1  and  is  currently  executing  on  the 


j 

i 


i 


CPU)  . 


TC_GETH0B1C  Procedure 
Begin 

VP_ID  :*  BONNING_VP 
Do  while  not  end  of  ready  list 
if  process  is  running  then 
get  next  ready  process 
else 

BONN ING_L  1ST  [VP_ID]  :=  PBOCESS_ID 
Process  state  :»  tunning 
SNiPJTDBB 
end  if 
end  do 

If  end  of  running  list  (no  ready  processes)  Then 
HONNING.LIST  :  =  #IDLE 
IDLE 
end  if 
Beturn 

End  TCGBTWORK 
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b.  TC_PR B  EM  PT_H  A  ND  LEB 

Preempt  interrupts  are  masked  while  a  process  is  execut¬ 
ing  in  the  kernel  domain.  As  the  process  leaves  the  kernel, 
the  gatekeeper  unmasks  this  virtual  interrupt  by  invoking 
TEST_VPHEBMPT.  This  instruction  tests  the  scheduled  VP's 
PREEMPT  flag.  If  this  flag  is  off,  the  process  returns  to 
the  Gatekeeper  and  exits  from  the  kernel;  out  if  the  flag  is 
set,  TEST_VPfiEEHPT  calls  the  Traffic  Controller's  virtual 
preempt  interrupt  handler,  TC_PH££MPT_HANDL2B .  This  handler 
invokes  TC.GETVOSK,  which  re-evaluates  level-2  scheduling. 
Eventually,  when  the  schedulers  have  completed  their  func¬ 
tions,  the  handler  will  return  control  to  the  preempted  pro¬ 
cess,  which  will  return  to  te  Gatekeeper  for  a  normal  exit. 
This  seguence  of  events  closely  parallels  the  action  of  a 
hardware  interrupt,  but  in  the  environment  of  a  virtual  pro¬ 
cessor  rather  than  a  CPU.  The  virtualization  of  interrupts 
provides  the  ability  for  one  virtual  processor  to  interrupt 
execution  of  another  that  may,  or  may  not,  be  running  on  a 
CPU  at  that  time.  This  is  provided  without  disrupting  the 
logical  structure  of  the  system.  This  capability  is  parti¬ 
cularly  useful  in  a  multiprocessor  environment  where  the 
target  virtual  processor  may  be  executing  on  another  CPU. 
Because  these  interrupts  will  be  virtualized,  the  operating 
system  will  retain  control  of  the  system.  The  action  of  the 
?C_?R2EBPT_HANDLER  is  described  in  the  procedure  below. 


143  - 


TC_PHEEHPT_H ANDLEH  Procedure 
Begin 

Call  MAIT.LOCK 

?P_ID  : =  RUNMINGJIP 

Process_ID  :=  BOMBING  LIST  [VP_ID] 

If  process  is  not  idle  Then 
Process  state  :*  ready 
end  if 

Call  TC.GETMOBK 
Call  BAIT_ONLOCK 
BE  TORN 

End  TC_PBEESPT_HA HOLER 

HAIT_LJCK  and  HAIT.ONLOCK  provide  an  exclusion  sechaniss 
which  prevents  sisultaneous  Multiple  use  of  the  APT  in  a 
•uniprocessor  configuration.  This  aechanisa  invoices  BAIT 
and  SIGNAL  of  the  Inner  Traffic  Controller. 


3.  siaatsaaaii 

In  eventcount  is  a  non- decreasing  integer  associated 
with  a  global  object  called  an  event  [11].  Ihe  Event  Manag¬ 
er,  a  leval-3  nodule,  controls  access  to  event  data  when  re¬ 
quired  and  provides  the  Traffic  Controller  with  a  HANDLE,  an 
INSTANCE,  and  a  COUNT.  The  values  for  all  aventcounts  (and 
sequencers)  are  aaintained  at  the  Memory  Manager  level  and 
are  accessed  by  calls  to  the  Meaory  Manager.  The  HANDLE 
provides  the  traffic  controller  with  an  event  ID,  associated 
with  a  particular  segaent.  INSTANCE  is  a  nore  specific  de¬ 
finition  of  the  event.  For  exaaple,  each  SASS  supervisor 
sequent  has  two  aventcounts  associated  with  it,  a  INST1MCE_1 
and  a  INSTANCE^,  that  the  supervisor  uses  keep  track  of 
read  and  write  access  to  the  segaent  [9].  Eventcounts  pro¬ 
vide  inforaation  concerning  system-wide  events.  They  are 
aanipulated  by  the  Traffic  Controller  functions  ADVANCE  and 
AN  AIT  and  by  the  Meaory  Manager  functions,  BEAD  and  TICK!.' 

A  proposed  high  level  design  for  ADVANCE  and  AH AIT  is  pro¬ 
vided  by  Beits  [12]. 

a.  Advance 

ADVANCE  signals  the  occurrence  of  an  event  (e.g.,  a  read 
access  to  a  particular  supervisor  segaent) .  The  value  of 
the  eventcount  is  the  nuaber  of  ADVANCE  operations  that  have 
been  perforaed  on  it.  Hhen  an  event  is  advanced,  the  fact 
aust  be  broadcast  to  all  blocked  processes  awaiting  it  and 
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the  process  east  be  awakened  and  placed  on  the  ready  list. 
Soae  of  the  newly  awakened  processes  aay  have  a  higher  pri- 
ority  than  soae  of  the  running  processes.  In  this  case  a 
virtual  preeapt,  SET_7PREEHPT  (7P_ID) ,  aust  be  sent  to  the 
virtual  processors  loaded  with  these  lower  priority  process¬ 
es. 

b .  Await 

When  a  process  desired  to  block  itself  until  a  particu¬ 
lar  event  occurs,  it  invokes  AHAIT.  this  procedure  returns 
to  the  calling  process  when  a  specified  eventcount  is 
reached.  Its  function  is  siailar  to  BAIT. 

c .  Read 

READ  returns  the  current  value  of  the  eventcount.  this 
is  an  Event  Hanager  (level  three)  function.  This  aodule 
calls  the  Heaory  Hanager  aodule  to  obtain  the  eventcount  va¬ 
lue. 

d .  Ticket 

TICKET  provides  a  coaplete  tiae-ordering  of  possibly 
concurrent  events.  It  uses  a  non-decreasing  integer,  called 
a  sequencer,  which  is  also  associated  with  each  supervisor 
segaent.  As  with  READ,  this  is  an  Event  Hanager  function 
that  calls  the  Heaory  Hanager  to  access  the  sequencer  value. 
Each  invocation  of  TICKET  increaents  the  value  of  the  se- 
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quencer  and  returns  it  to  the  caller.  Two  different  uses  of 
ticket  will  return  two  different  values,  corresponding  to 
the  order  in  which  the  calls  were  aade. 

d.  515188  UimUlillfifi 

Because  the  Inner  Traffic  Controller's  scheduler, 
GETSORK,  can  accoanodate  both  nornal  calls  and  hardware  in¬ 
terrupt  juaps,  the  problea  of  system  initialization  is  not 
difficult. 

When  SASS  is  first  started  at  level- 1,  the  Idle  7P  is 
running  and  the  neaory  aanager  VP,  which  has  the  highest 
priority,  is  the  first  ready  virtual  processor  in  the  ready 
list.  All  VP's  available  to  the  Traffic  Controller  for  lev- 
el-2  schedling  are  ready.  Their  IDLE_?LAG's  and  PREEMPT 
flags  are  set. 

At  level-2,  all  VP's  are  loaded  with  idle  processes  and 
all  supervisor  processes  are  ready. 

The  kernel  stack  segnect  of  each  process  is  initialized 
to  appear  as  if  it  had  been  saved  by  a  hardware  Preeapt  in¬ 
terrupt  (Figure  40)  . 

All  CPU  registers  and  the  supervisor  stack  pointer  are 
stored  on  the  stack.  R15  is  reserved  as  the  kernel  stack 
point;  R 1 4  contains  the  DBB.  All  other  registers  can  be 
used  to  pass  initial  paraneters  to  the  process.  The  order 
in  which  these  registers  appear  on  the  stack  supports  the 
PLZ/ASM  block-nove  instructions. 
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Stack  Segaent 
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process  entry 
ker  stack  ptr 
raET  FLAG 


ker  pch 


header 


Pigure  40:  Initialized  Stack 
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The  status  block  contains  the  current  value  of  the  stack 
pointer.  Hi  5,  and  the  preempt  interrupt  return  flag.  This 
flag  is  set  to  indicate  that  the  process  has  been  saved  by  a 
preempt  interrupt.  The  first  three  items  on  the  stack:  the 
process  entry  point,  the  initial  process  flag  control  word, 
and  an  interrupt  indentifier,  are  also  initialized  to  sup¬ 
port  the  action  of  a  hardware  interrupt. 

To  start-up  the  system,  a  14  (the  DBR)  is  set  to  the  Idle 
process  DBR;  the  CPU  Program  counter  is  assigned  the 
PREEMPT.ENTRr  point  in  GETWORK;  the  CPO  Flag  Control  word 
(PCW)  is  initialized  for  the  kernel  domain;  and  the  CPU  is 
started.  Because  the  Idle_VP  is  the  lowest  priority  VP  in 
the  system,  it  will  place  itself  back  in  the  ready  state  and 
move  the  Memory  Manager  in  the  running  state.  The  Memory 
Manager  will  execute  an  interrupt  return  because  the  inter¬ 
rupt  return  flag  was  set  by  system  initialization.  There 
will  be  no  work  for  this  kernel  process  so  it  will  call  WAIT 
to  place  itself  in  the  waiting  state.  The  next  ready  VP  is 
idling,  but  since  it's  IDL3_FL AG  and  PREEMPT  flag  are  set, 
GETWORK  will  select  it.  It  too  will  execute  an  interrupt 
return,  but  because  its  PREEMPT  flag  is  set,  it  will  call 
TC_PREEMPT_H AHDLEP. .  This  will  cause  the  first  ready  process 
to  be  scheduled.  Each  time  a  supervisor  process  blocks  it¬ 
self,  the  next  idle  VP  will  be  selected  and  the  seguence 
will  be  repeated. 


AD-A109  553  NAVAL  POSTGRADUATE  SCHOOL  MONTEREY  CA  F/6  9/2 

THE  NAVAL  POSTSRADUATE  SCHOOL  SECURE  ARCHIVAL  STORAGE  SYSTEM.  P— ETC(U> 
MAR  fli  L  A  COX#  R  R  SCHELL#  S  L  PERDUE 
UNCLASSIFIED  NPS52-81-001  NL 


The  action  described  above  is  in  accord  with  noraal  op¬ 
eration  of  the  systea.  The  only  unique  features  of  initial¬ 
ization  are  the  entry  point  (PEBEEPT-BMT&I:  in  GETVOAR)  and 
the  values  in  the  initialized  kernel  stack. 

The  iapleaentation  presented  in  this  thesis  has  been  run 
on  a  Z8000  developmental  aodule.  systea  initialization  has 
been  tested  and  executes  correctly.  At  the  current  level  of 
iapleaentation,  no  process  aultiplexing  function  is  availa¬ 
ble.  There  is  no  provision  for  unlocking  the  APT  after  an 
initialized  process  has  been  loaded  as  a  result,  a  call  to 
the  Traffic  Controller  (viz.,  ADTAHCE  or  AHAIT) .  In  a  pro¬ 
cess  aultiplexed  environaent  this  would  cause  a  systea  dead¬ 
lock.  Once  the  process  left  the  kernel  doaain  with  a  locked 
APT,  no  process  would  be  able  to  unlock  it.  The  Traffic 
Controller  aust  handle  this  systea  initialization  problea. 


Chapter  XT 

covcLOsioa 

The  implementation  presented  in  this  thesis  created  a 
security  kernel  aonitor  that  runs  on  the  Z8000  Developmental 
Module.  This  aonitor  supports  multiprogramming  and  process 
nanageaent  in  a  distributed  operating  systea.  The  process 
executes  in  a  nultiple  virtual  processor  environment  which 
is  independent  of  the  CPO  configuration. 

This  aonitor  was  designed  specifically  to  support  the 
Secure  Archival  Storage  Systea  (SASS)  [2,  9,  5].  However, 
the  iapleaentation  is  based  on  a  family  of  Operating  Systeas 
[7]  designed  with  a  primary  goal  of  providing  multilevel  se¬ 
curity  of  inforaation.  Although  the  aonitor  currently  runs 
on  a  single  aicroprocessor  systea,  the  iapleaentation  fully 
supports  a  aultiprocessor  design. 

A.  BK2S8MfiilION5 

Because  the  Zilog  MHO  is  not  yet  available  for  the  Z80G0 
Developmental  Module,  it  was  necesary  to  siaulate  the  seg¬ 
mentation  hardware.  As  Beitz  explained  [12],  this  was  ac¬ 
complished  by  reserving  a  CPO  register,  B14,  as  a  Descriptor 
Base  Register  (DBR)  to  provide  a  link  to  the  loaded  addresss 
space.  When  the  MHO  becoaes  available,  this  siaulation  must 
be  reaoved.  This  can  be  done  in  two  steps. 
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First,  the  addressing  foraat  sust  be  translated  to  the 
segaented  fora.  This  requires  no  systea  redesign. 

Second,  the  switching  aechanisa  aost  be  aodified  to  ac- 
coaodated  to  use  the  MHO.  This  can  be  done  by  aodifying  the 
S»AP_DBB  portion  of  GETHOBK  to  aultiplex  the  BH0_iaAGB  onto 
the  BHU  hardware  and  this  can  be  accoaplished  by  changing 
about  a  dozen  lines  of  the  existing  code. 

b.  £211.28  31  82&£ 

Although  the  aonitor  appears  to  execute  correctly,  it 
has  not  been  rigorously  tested.  Before  higher  levels  of  the 
systea  are  added,  it  is  essential  that  the  aonitor  be  highly 
reliable.  Therefore  a  formal  test  and  evaluation  plan 
should  be  developed. 

An  automated  systea  generation  and  initialization  ae- 
chanisa  is  also  required  if  the  aonitor  to  be  is  a  useful 
tool  in  the  developaent  of  higher  levels  of  the  design. 

Once  the  aonitor  has  been  proven  reliable  and  can  be 
loaded  easily,  work  on  the  iapleaentation  of  the  Heaory  Man¬ 
ager  kernel  process  and  the  reaainder  of  the  kernel  can  con¬ 
tinue. 
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PART  B 

IMPLEMENTATION  OP  SEGMENT  MANAGEMENT  FOR  A 
SECORB  ARCHIVAL  STORAGE  SISTER 


This  section  contains  excerpts  froa  a  Naval  Postgraduate 
School  HS  Thesis  by  J.  T.  Hells  [20].  The  origins  of  these 
excerpts  are: 


INTRODUCTION 

SEGMENT  MANAGEMENT  FUNCTIONS 
SEGMENT  MANAGER 

NON -DISCRETIONARY  SECURITY  MODULE 

MEMORY  MANAGER 

SUMMARY 

SEGMENT  MANAGEMENT  IMPLEMENTATION 
CONCLUSIONS  AND  FOLLQH  ON  HORN 


froa  Chapter 


froa  Chapter  II 
froa  Chapter  III 
froa  Chapter  IV 


Minor  changes  have  been  aade  for  integration  into  this  report. 
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Chapter  XVI 
IITBODOCTIOM 

This  thesis  addresses  the  iepleeeatation  of  the  segaent 
management  functions  of  an  operating  system  known  as  the  Se¬ 
cure  archival  Storage  Systea  or  SASS.  This  system,  with  full 
implementation,  will  provide:  (1)  multilevel  secure  access 
to  inforaation  (files)  stored  in  a  "data  warehouse"  for  a 
network  of  aultiple  host  computers,  and  (2)  controlled  data 
sharing  among  authorized  users.  The  correct  perforaance  of 
both  of  these  features  is -directly  dependent  upon  the  prop¬ 
er  implementation  of  the  segment  management  functions  ad¬ 
dressed  in  this  thesis.  The  issue  of  access  to  sensitive  in¬ 
foraation  is  addressed  by  the  Hon-Discretionary  Security 
Hodule,  which  mediates  all  non- discretionary  access  to  in¬ 
formation.  Sharing  of  inforaation  is  accomplished  chiefly 
through  the  properties  of  segmentation,  the  SASS  memory  man¬ 
agement  scheme  that  is  supported  by  the  Memory  Manager  Ho¬ 
dule  and  the  Segaent  Manager  Module.  The  implementation  of 
segaent  management  for  SASS  is  thus  integral  to  the  attain¬ 
ment  of  the  two  key  goals  that  SASS  was  designed  to  achieve. 
This  implementation  addresses  the  Mon-Discretionary  securi¬ 
ty,  Distributed  Memory  Manager  (the  interface  to  the  Memory 
Manager  Process),  and  Segment  Manager  modules. 
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Chapter  mi 

SEGMENT  MANAGEMENT  POHCZIOIS 

».  5555511  5414555 

i .  EaacUsa 

The  Segment  Manager  is  the  focal  point  of  the  segment 
aanageaent  function.  Osing  the  per-process  Known  Segaent  Ta¬ 
ble  as  its  database  and  the  Memory  Manager  and  Non-Discre- 
tionary  Security  Module  in  strongly  supportive  roles*  it  is 
responsible  for  managing  the  segmented  virtual  memory  for  a 
process.  Its  role  can  be  viewed  as  somewhat  intermediary  in 
nature  (viz.,  between  the  Supervisor  modules  and  the  Memory 
Manager  modules) .  The  extended  instruction  set  created  in 
the  Segaent  Manager  includes  the  following  instructions: 
CREATE.SEGMENT,  DELETERS  EGMENT,  MAKEJCNOHN,  TERMINATE 
SM_S«AP_IN,  and  Sl?_S«APJ}UT  (note  that  the  names  for  SHAP_IN 
and  swap_OGT  have  been  modified  by  preceding  each  with  SS_; 
this  is  strictly  for  clarity  because  the  Memory  Manager  also 
creates  two  instructions  called  SBAP.IN  and  SHAP_0UT) . 
These  instructions  are  invoiced  by  the  Supervisor  domain  of 
the  process  (viz.,  calls  are  made  from  the  Supervisor  domain 
via  the  Gatekeeper  to  the  Segment  Manager  in  the  Kernel  do¬ 
main)  to  provide  SASS  support  to  the  Host. 


In  general,  when  the  Segaent  Manager  receives  these 
calls,  it  performs  certain  checks  to  ensure  the  validity  and 
security  compliance  (when  required)  of  the  request  (call) . 
These  checks  are  perforaed  using  its  own  database  (the  KST) 
and  by  calls  to  the  Hon-Discretionary  Security  Module  (when 
required) .  The  Segaent  Manager  invokes  one  of  six  Memory 
Manager  (more  specifically,  the  Distributed  Meaory  Manager 
Module)  created  instructions.  These  instructions  include: 
MN_CB2AT2_3NTBT ,  MM_DEL2TE_2NTBY ,  HM_ACTI¥ATE, 
MH_DE ACTIVATE,  MM_SBiP_IH,  and  MM_SBiPj)OT.  These  invoked 
instructions  (procedures)  in  turn  perforn  interprocess  coa- 
aunciations  with  the  non-distributed  memory  manager  process 
(where  actual  aeaory  aanageaent  functions  are  accoaplished) . 
These  interprocess  invocations  and  returns  are  accoaplished 
through  the  use  of  the  IPC  primitives  Signal  and  Bait.  The 
Segaent  Manager  returns  the  required  arguments  to  the  Super¬ 
visor  by  value  (as  passed  back  to  it  by  the  Meaory  Manager 
and/or  determined  within  itself) .  The  Segaent  Manager  per- 
foras  actual  segaent  number  assignaent  when  a  segaent  is 
made  known  to  a  process*  address  space.  It  also  performs 
any  further  database  (KST)  updating  as  may  be  required. 

2.  sm&ici 

The  Known  Segment  Table  (KST)  is  the  database  used  to 
aanage  segaents.  The  KST  is  described  in  its  tabular  fora 
and  PLZ/STS  structured  representation  in  figure  41.  There 
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are  several  basic  and  pertinent  facts  to  be  noted  of  the 
KST: 


1.  It  is  a  process  local  database;  that  is,  each  process 
has  its  own  KST. 

2.  The  KST  is  indexed  by  segaent  nueber;  each  record  of 
the  KST  consists  of  a  set  of  fields  (description  in¬ 
formation)  regarding  a  particular  segaent. 

3.  Entering  inforaation  into  the  fields  of  a  segaent  is 
called  "aaking  a  segaent  known1*.  This  siaply  refers 

'  to  adding  a  segaent  to  a  process*  address  space 
(viz.,  aaking  a  segaent  accessible  to  a  process). 

4.  In  SASS,  a  correspondence  exists  between  aaking  a 
segaent  "known"  and  aaking  a  segaent  "active";  i.e., 
when  a  segaent  is  added  to  the  address  space  of  a 
process,  this  action  results  in  an  entry  in  the  KST 

(aaking  "known")  by  the  Segaent  Manager  and  an  entry 

« 

in  the  Global  Active  Segaent  Table  (G_AST)  by  the  He- 
aory  Manager  process  (aaking  it  "active") .  The  G_AST 
will  be  described  later  in  this  chapter. 

A  proper  description  of  the  structure  and  fields  of  the  KST 
is  necessary  at  this  point.  Using  the  representation  of  the 
PLZ/SYS  language  structure,  the  KST  is  described  as  an  array 
of  records  of  fields  of  varying  types.  The  fields  are  de¬ 
scribed  separately  below.  Although  the  KST  index  is  not  in 
itself  a  field  in  the  record,  it  does  perfora  a  rather  sig¬ 
nificant  role.  The  KST  index  is  an  integer  closely  related 


to  the  segaent  number  of  the  segaent  described  in  that  KST 
entry  (viz.,  it  is  the  subscript  into  the  array  of  records). 
This  segaent  nuaber  also  corresponds  to  the  BBO  descriptor 
register  (nuaber)  for  that  segaent. 

The  BH_aandle  is  the  first  field  in  a  KST  record.  The 
BB.Handle  is  a  systea  aide  unique  nuaber  that  is  assigned  to 
each  segaent  with  an  entry  in  the  G_1ST  (viz.,  every  active 
segaent)  .  This  "handle"  is  the  instrument  of  controlled  sin- 
gle  copy  sharing  of  information  (segments) .  it  allows  a  seg¬ 
ment  to  exist  under  one  unique  handle  but  be  accessible  in 
the  address  space  of  more  than  one  process  (with  different 
segment  nuabers  in  each  address  space).  The  BB^Handle  is  re¬ 
turned  to  the  segment  Banager  by  the  Beaory  Manager  during 
the  execution  of  the  Bake_Known  instruction. 

The  size  field  is  an  integer  value  (of  language  struc¬ 
ture  type  "word")  which  represents  the  nuaber  of  256  byte 
blocks  coaposing  a  segaent. 

The  &ccess_Bode  field  is  used  to  describe  the  process' 
access  to  the  segaent  (i.e.,  null  or  read  and/or  write). 

The  In.Core  field  is  used  to  indicate  if  the  segaent  is 
or  is  not  in  aain  memory  (i.e.,  this  field  is  a  flag  or 
true/false  boolean  switch) . 

The  Class  field  is  a  long  word  field  used  to  represent 
the  degree  of  inforaation  sensitivity  (viz.,  access  class) 
assigned  to  the  segaent.  This  field  (for  exaaple)  would  be 
used  to  nuaerically  describe  a  classification  label  (as  de¬ 
scribed  above) . 
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Figure  41:  Known  Segaent  Table 
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The  Mentor_Seg_Nr  field  is  a  number  representing  the 
segaent  nuaber  of  a  segment's  parent  or  "aentor"  segment. 
Its  iaportance  will  discussed  shortly. 

The  Bntry_Nr  field  is  a  number  representing  a  segment's 
index  number  into  its  parent  or  aentor  segment's  Alias  Table 
(not  yet  discussed) . 

The  Alias  Table  is  a  Memory  Manager  database  and  will  be 
described  later.  The  aliasing  scheme  provided  via  the  alias 
tables  is  used  to  prevent  passing  system  wide  information 
out  of  the  Kernel  (i.e.,  the  Unigue_ID  of  a  segaent).  The 
"alias"  of  a  segaent  is  the  concatenation  of  the  Men- 
tor_Seg_Nr  with  the  segment's  Entry_Br  (index)  into  the  aen¬ 
tor  segment's  Alias  Table.  It  is  clear  that  the  last  two 
fields  of  a  KST  record  are  the  "alias"  of  that  segment. 

b.  saikMSgmifliAfii  sKSBiix  asaa jj 

The  key  in  protection  of  secure  information  using  inter¬ 
nal  controls  was  identified  as  the  security  kernel  concept. 
The  basic  idea  within  this  concept  is  to  prove  the  hardware 
part  of  the  Kernel  correct  and,  similarly,  to  keep  the  soft¬ 
ware  part  small  enough  so  that  proving  it  correct  is  feasi¬ 
ble.  A  central  component  of  the  kernel  software  is  the 
Non-Discretionary  Security  Module  (hereafter  referred  to  as 
the  HDS  Module) .  The  HDS  Module  is  concerned  only  with  the 
non-discretionary  aspect  of  the  security  policy  in  effect; 
since  the  discretionary  aspect  is  subservient  in  nature  to 
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the  non-discretionary  aspect,  it  is  thee  sufficient  that  the 
Kernel  contain  only  the  software  representing  the  non-dis- 
cretionary  aspect  of  the  security  policy.  The  discretionary 
security  is  provided  outside  the  kernel  in  the  SASS  supervi¬ 
sor.  Every  attempt  to  access  information  must  result  in  an 
invocation  of  the  NDS  Module. 

The  function  of  the  NDS  Module  is  to  compare  two  classi¬ 
fications  (viz.,  compare  two  labels),  make  a  decision  as  to 
their  relationship  (i.e.,  =,>,<,!),  and  return  a  true/false 
interpretive  answer  relative  to  the  guery  of  the  calling 
procedure.  The  mechanism  used  as  a  basis  is  the  lattice  mo¬ 
del  abstraction  previously  discussed.  The  NDS  Module  does 
not  require  a  database  since  the  labels  it  compares  are 
snored  in  (passed  from)  other  Kernel  databases. 

C.  MEBOST  MAW AGEE 
1 •  ZMBSt ioa 

The  Memory  Manager  process  is  the  only  component  of  the 
non-distributed  kernel.  It  is  responsible  for  managing  the 
real  memory  resources  of  the  system  —  main  (local  and  glo¬ 
bal)  menory  and  secondary  storage.  It  is  tasked  by  other 
processes  within  the  Kernel  domain  (via  Signal  and  Wait)  to 
perform  aemory  management  functions.  This  thesis  will  ad¬ 
dress  the  Memory  Manager  in  terms  of  two  components:  (1)  the 
Memory  Manager  Process  (also  called  the  nondistributed  ker¬ 
nel  and  the  Memory  Manager  Module),  and  (2)  the  distributed 
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Meaory  Manager  (also  called  the  Distributed  Meaory  Manager 
Module) .  The  foraer  is  the  "true"  sesory  sanager  while  the 
latter  is  the  interface  with  other  processes,  that  is,  it 
resolves  the  issue  of  interprocess  coaaunication  with  the 
"true"  aeaory  aanager. 

The  Distributed  Meaory  Manager  Module  creates  the  fol¬ 
lowing  extended  instruction  set:  MM_CBEATE_E1ITBT, 
MM_DELETE_ENTBY,  HM_ACTIVATE,  MM_DE ACTIVATE,  MM_S»AP_IH,  and 
MM_SHAP_0UT .  The  instructions  fora  the  aechanisa  of  coaauni- 
cation  between  the  Segaent  Manager  of  a  process  and  a  aeaory 
aanager  process  (where  the  actual  aeaory  aanageaent  func¬ 
tions  are  perforaed) .  The  Meaory  Manager  Process  instruction 
set  corresponds  one  to  one  with  that  of  the  Distributed  Me- 
aory  Manager;  the  set  consists  of:  CBEATE^EMTRY, 
DELETE_ENTR Y,  ACTIVATE,  DEACTIVATE,  SHAP_IN,  and  SHAPJJUT. 
The  basic  functions  perforaed  by  the  Meaory  aanager  are  al¬ 
location/deallocation  of  global  and  local  aeaory  and  of  sec¬ 
ondary  storage,  and  segaent  transfers  froa  local  to  global 
aeaory  (and  vice-versa)  and  froa  secondary  storage  to  aain 
aeaory  (and  vice-versa) . 

2.  Cailfe45§§ 

A  detailed  and  descriptive  discussion  of  the  Meaory  Man¬ 
ager  databases  is  presented  in  the  work  of  Gary  and  Moore 
[5],  and  the  reader  aay  refer  to  it  for  aeaory  aanager  data¬ 
base  details.  This  thesis  addresses  the  iapleaentation  of 
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the  distributed  Meaory  Manager  but  not  the  Meaory  Manager 
Process,  thus  brief  descriptions  are  provided  of  the  lat¬ 
ter's  databases. 

The  Global  Active  Segment  Table  (G.AST)  is  a  systea  vide 
(i.e. ,  shared  by  all  aeaory  manager  processes)  database  used 
to  manage  all  active  segaents.  A  lock/unlock  mechanism  is 
used  to  prevent  race  conditions  froa  occurring.  The  distri¬ 
buted  aeaory  manager  of  the  signalling  process  locks  the 
G_AST  before  it  signals  the  aeaory  manager  process. 

The  Local  Active  Segment  Table  (L..AST)  is  a  processor 
local  database  which  contains  an  entry  for  each  segment  ac¬ 
tive  in  a  process  currently  loaded  in  local  aeaory. 

The  Alias  Table  is  a  systea  vide  database  associated 
with  each  nonleaf  segment  in  the  Kernel.  It  is  a  product  of 
the  aliasing  scheme  used  to  prevent  passing  systea  vide  in¬ 
formation  out  of  the  Kernel.  The  alias  table  header  (provid¬ 
ed  for  file  systea  reconstruction  after  system  crashes)  has 
two  pointers,  one  linking  the  alias  table  to  its  associated 
segaent,  the  other  linking  the  alias  table  to  the  mentor 
segment's  alias  table.  The  fields  in  the  alias  table  are 
Unique_ID,  Size,  Class,  Page_Table_Loc,  and  Alias_TableJLoc. 
The  index  into  the  alias  table  is  Entry_No. 

The  Meaory  Management  Unit  Image  (MMG.Zaage,  Figure  42) 
is  a  processor  local  database  indexed  by  DBB_No  (viz.,  for 
each  DBR_Mo  there  is  a  MHU_Iaage  record,  with  each  record 
containing  a  software  image  of  the  segaent  descriptor  regis- 
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tars  of  the  hardware  HMD) .  The  MHO.Iaage  is  aa  exact  iaage 
of  the  MMO.  Each  record  is  indexed  by  Segaent_Ho  (segaent 
nuaber)  and  each  Segnent_Ho  entry  contains  three  fields.  The 
Base.lddr  field  contains  the  segaent* s  base  address  in  neao- 
ry.  The  Liait  field  contains  the  nuaber  of  blocks  of  conti¬ 
guous  storage  for  the  segaent  (zero  indicates  one  block) . 
The  attributes  field  contains  8  flags  including  5  which  re¬ 
late  to  the  aeaory  aanager.  The  Blks_0sed  field  and  the 
Max_Blks  (available)  fields  are  per  record  (not  per  segaent 
entry)  and  are  used  in  the  aanageaent  of 
each  process'  virtual  core. 

The  Meaory  Bit  Maps  (Disk_Bit_Map»  Glo- 
bal_Meaory_Bit_Hap,  and  Local_Meaory_Bit_Map)  are  aeaory 
block  usage  aaps  that  use  true/false  flags  (bits)  to  indi¬ 
cate  the  use  or  availability  of  storage  blocks. 

The  only  database  in  the  Distributed  Neaory  Manager  is 
the  Meaory  Manager  CPO  Table  (Figure  43) .  it  is  an  array  of 
aeaory  aanager  VP_ZD's  (HM_?P_ID)  indexed  by  CPO  nuaber. 
This  table  enables  a  signalling  process  to  identify  the  ap¬ 
propriate  aeaory  aanager  process  (virtual  processor)  to  sig¬ 
nal. 
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Figure  42:  Henory  Manageaeat  Unit  Iaage 
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BB.YP.ID 

CPO 
I 
I 
I 
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Figure  43:  Neaory  Manager-CPO  Table 

o.  sauux 

The  segaent  aanageaent  functions  and  Icey  related  con¬ 
cepts  (such  as  segaentation)  were  discussed  in  this  chapter. 
The  iaportance  of  sagaentation  to  data  sharing  and  inforaa- 
tion  security  was  eaphasized  as  were  hey  inforaation  securi¬ 
ty  concepts.  With  this  bach ground,  the  iapleaentation  of 
segaent  aanageaent  and  a  non-discretionary  security  policy 
will  be  described  in  the  following  chapter. 
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Chapter  XVIII 

SEGMENT  MANAGEMENT  IBPLEBEIXAIIOI 
The  implementation  of  segaent  eanageaent  functions  and  a 
non-discretionary  security  policy  is  presented  in  this  chap¬ 
ter.  Paramount  to  this  implementation  mere  several  key  is¬ 
sues  that  affected  the  implementation.  These  issues  are  dis¬ 
cussed  first.  The  implementation  is  discussed  in  terms  of 
the  Segaent  Manager,  Non- Discretionary  Security  (NDS) ,  and 
Distributed  Memory  Manager  nodules. 

A.  IJ&JifiBSmmi  ISSQBS 

Segment  management  for  the  SASS  vas  provided  through  the  im¬ 
plementation  of  the  Segment  Manager  Module,  the  NDS  Module, 
and  the  Distributed  Memory  Manager  Module.  Additionally, 
since  a  demonstration/testbed  was  integral  to  the  testing 
and  verification  of  the  implementation,  it  was  necessary  to 
complete  other  supportive  tasks.  Reitz  [12]  provided  a  de¬ 
monstration  of  the  operation  of  the  Inner  Traffic  Controller 
primitives  SIGNAL  and  N AIT  (for  interprocess  communica¬ 
tion)  .  Integral  to  this  demonstration  vas  the  correct  per¬ 
formance  of  the  Inner  Traffic  Controller  VP  scheduling  me¬ 
chanism  and  a  "stub"  of  the  Traffic  Controller  and  its 
process  scheduling  mechanism  (the  TC  support  and  use  of  the 


aechanisa  of  eventcounts  and  sequencers  was  not  a  part  of 
the  demonstration) .  The  Segment  aanagesent  desonstration 
(hereafter  referred  to  as  "Seg.Hgr. Oeao")  was  "built  on  top 
of"  Seitz*  ZTC  synchronization  primitive  demonstration 
(hereafter  referred  to  as  "Sync.  Deno") .  Thus,  an  iaaediate 
issue  was  to  resolve  the  feasibility  of  adding  on  to 
Sync. Oeao  and  also  to  refine  the  present  design  of  the  Sync. 
Oeao  to  facilitate  its  integration  into  the  seg.Hgr.Oeao. 
One  aspect  of  this  effort  was  in  resolving  the  problea  of 
how  to  pass  (i. e. ,  in  interprocess  coaaunication)  a  larger 
aessage. 

i*  x&ticBc&fiiis  ai«»n 

The  Sync.Deao  passed  "word"  (16  bit)  aessages.  To  pro* 
vide  the  aechanisa  for  the  distributed  aeaory  manager  to 
signal  the  aeaory  aanager  process  with  a  command  function 
identification  code  and  the  arguaents  needed  to  perfora  that 
function  (e.g.,  CHEATE-EMT11T  and  its  input  arguaents),  a 
aessage  size  of  at  least  eight  words  (16  bytes)  was  neces¬ 
sary.  An  obvious  answer  was  to  signal  with  an  array  of 
eight  words  as  the  aessage.  PLZ/STS,  however,  does  not  al¬ 
low  passing  arrays  in  its  procedure  calls  (a  procedure  call 
is  analogous  to  a  subroutine  call).  Another  alternative  was 
to  signal  with  a  pointer  to  the  array  of  words,  since 
PLZ/STS  does  allow  passing  pointers  in  procedure  calls  (thus 
the  aessage  would  be  a  pointer  to  the  real  aessage) .  This, 


however,  would  be  invalid  in  the  segmented  implementation 
(on  the  28000  segmented  microprocessor)  since  identical  seg¬ 
ment  numbers  in  different  processes  say  not  refer  to  identi¬ 
cal  segments.  For  example,  a  pointer  in  a  process  (e.g., 
file  management)  points  to  an  array  (i.e.,  provides  its  ad¬ 
dress)  by  segment  number  and  offset;  passing  this  pointer  to 
another  process  (e.g.,  memory  manager)  would  provide  this 
same  segment  number  and  offset  which,  of  course,  may  be  a 
different  object  in  the  second  process's  address  space). 

Another  alternative  considered  was  that  of  a  shared 
"Mailbox"  segment  with  an  associated  eventcount  acted  on  by 
the  Kernel  Inner  Traffic  Controller  primitives 
TICKET, ADVANCE  and  AWAIT.  A  design  for  using  this  concept 
in  the  supervisor  ring  is  provided  by  Parts  [9],  This  al¬ 
ternative  was  not  deeply  considered  since  these  primitives 
are  not  included  in  the  current  Inner  Traffic  Controller. 

The  method  ultimately  used  to  signal  the  new  length  mes¬ 
sages  is  based  on  the  fact  that  the  ITC  is  in  both  the  sig¬ 
nalling  and  the  receiving  (memory  manager)  processes'  ad¬ 
dress  space.  The  message  is  loaded  into  an  array  in  process 
#1  and  a  pointer  to  the  array  is  passed  in  the  call  SIGNAL; 
the  vpt,  the  ITC's  database,  is  then  updated  by  (using  the 
pointer)  putting  the  message  into  its  HSG_Q  section.  The 
message  is  retrieved  by  process  #2  by  execution  of  Beitz* 
WAIT  primitive  with  only  one  refinement.  That  refinement  is 
for  the  "waiting1*  process  to  provide  as  an  argument  (in  the 
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WAIT  primitive)  a  pointer  to  its  own  aessage  array  so  that 
the  aessage  in  the  VPT  can  be  copied  to  it.  This  refineaent 
provides  for  passing  a  long  aessage  essentially  "by  value" 
between  processes. 

2.  SiMsfcaisa  as  Aiaaiaais 

Another  issue  concerned  the  use  of  pointers  in  the  im- 
pleaentation  of  segaent  aaca^eaen^.  This  necessary  "evil" 
is  a  result  of  the  need  to  *4ss  linguistically  "complex" 
data  types  in  procedure  calls.  Coaplex  types  refer  to  array 
and  record  structures  in  PLZ/SIS  (as  opposed  to  the  "siaple" 
types — byte,  word,  integer,  short-integer,  long,  and  poin¬ 
ter).  In  aanaging  databases  (e.  g.  ,  KSI,  G_AST)  which  con¬ 
sist  of  arrays  of  records  (which  in  turn  contain  records 
and/or  arrays) ,  it  was  frequently  necessary  to  reference 
data  as  an  array  or  record.  Within  a  process,  the  use  of 
pointers  was  not  a  problem  (i.e.,  not  a  probles  such  as 
would  be  encountered  in  IPC  passing  of  pointers). 

3.  Sttalcaai  safla 

The  issue  of  code  reentrancy  was  addressed  at  the  assea- 
bly  language  level  through  the  use  of  a  stack  segaent  and 
registers  for  storage  of  local  variables.  PLZ/SYS  (high 
level  language)  does  not  address  reentrant  procedures  and 
thus  the  sagaent  management  high  level  code  is  not  automati¬ 
cally  reentrant.  The  problem  of  reentrancy  can  be  seen  by 
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looking  at  a  shared  procedure  that  is  not  reentrant;  such  a 
procedure  has  storage  for  its  variables  allocated  statically 
in  aeeory.  Suppose  a  procedure  (e. g.,  in  the  Kernel)  can  be 
activated  by  aora  than  one  process.  Hhile  the  procedure  is 
executing  in  one  process*  a  process  switch  occurs  (e.g.*  to 
wait  for  a  disk  transfer)  and  its  execution  is  suspended. 
The  second  process  is  activated*  and  while  it  is  running  it 
invokes  the  procedure.  Ihile  the  procedure  is  executing  for 
the  second  process  it  uses  the  sane  storage  space  for  varia¬ 
bles  as  it  did  when  executing  for  the  first  process.  Eventu¬ 
ally,  it  relinquishes  the  processor.  However*  when  the 
procedure  cesuaes  its  execution  for  the  first  process*  the 
variable  values  that  were  in  use  by  it  originally  have  been 
changed  during  its  execution  in  the  second  process.  Thus, 
incorrect  results  ate  now  inevitable. 

Et sfifisa  ssiasisn  of  £ba  Asiscx  fla&asit 

Heferences  to  the  "Heaory  Manager"  in  past  works  have 
generally  aeant  the  aeaory  aanager  process  (non- distributed 
kernel).  This  work  references  two  distinct  coaponents  of 
the  "aeaory  aanager  nodule".  The  Distributed  Heaory  Hanager 
is  an  interface  provided  to  the  Heaory  Hanager  Frocess.  It 
is*  in  fact*  distributed  in  the  address  space  of  each  Super¬ 
visor  process.  In  contrast*  the  Heaory  Hanager  Process 
clearly  is  not  distributed  and  its  address  space  is  con¬ 
tained  entirely  in  the  Kernel. 
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5.  £SEr£E2SS22  5S2S2  S12122&  Ia21S 

Another  key  issue  was  that  of  the  per  process  Segeent 

Banager  database,  the  KST.  Since  each  process  has  its  own 
KST,  it  cannot  be  linked  to  the  (shared)  segaent  aanager 
procedures.  To  iapleaent  the  KST  as  a  per  process  database, 
it  was  convenient  to  establish,  by  convention,  a  KST  segaent 
nuaber  that  is  consistent  froa  process  to  process.  That 
segaent  in  each  process  is  the  KST  segaent  for  that  process. 
Iapleaentation  is  then  accoaplished  by  using  the  segaent 
nuaber  to  construct  a  pointer  to  the  base  of  the  appropriate 
KST.  It  is  then  easy  to  calculate  an  appropriate  offset  to 
index  any  desired  entry  in  the  KST  data. 

6.  £88  !4Adl2 

In  Feitz*s  iapleaentation  of  the  aultilevel  scheduler 
and  the  IPC  priaitives,  references  to  "DBB"  (descriptor  base 
register)  are  references  to  an  address.  That  address  value 
represents  a  pointer  to  an  BBU_ISAGE  record  containing  the 
list  of  descriptors  for  segaents  in  the  process  address 
space.  Gary  and  floore  [5]  reference  a  that  is  es¬ 

sentially  a  handle  used  within  the  aeaory  aanager  as  an  in¬ 
dex  within  the  BBU_IBAGE  to  a  particular  BBS  record.  The 
base  address  of  the  BBO  record  indexed  by  DBS. NO  is  then 
equivalent  to  the  concept  of  DB£  value  used  in  Seitz'  work. 
The  effect  of  this  inconsistency  on  the  segaent  aanageaent 
iapleaentation  was  ainor  and  will  be  further  discussed  later 
in  this  chapter. 
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b.  sssflBsx  amm  hopolb 

The  Segaent  Manager  Module  consists  of  six  procedures 
representing  the  six  extended  instructions  it  provides. 
These  are  based  on  the  design  of  Coleaan  [2].  Only  calls 
froa  external  to  the  Kernel  (via  the  Gate  Keeper)  aay  be 
aade  to  the  segaent  Manager  (per  the  loop-free  structure  of 
the  SASS) .  The  noraal  sequence  of  invocation  of  the  Segaent 
Manager  functions  to  allow  referencing  a  segaent  is:  (1) 
CREATE_SEG ME NT- -allocate  secondary  storage  for  the  segaent 
and  update  the  aentor  segaent's  Alias  Table,  (2) 
BAKE.. KNOWN— add  the  segaent  to  the  process  address  space 
(segaent  nuaber  is  assigned),  (3)  SWAP_IN— aove  the  segaent 
froa  secondary  storage  into  the  process's  aain  aeaory.  The 
noraal  sequence  of  invocation  to  "undo"  the  above  is:  (1) 
SWAP_OOT— aove  the  segaent  froa  aain  aeaory  to  secondary 
storage,  (2)  TERMINATE— re  aove  the  segaent  froa  the  pro¬ 
cess's  address  space,  (3)  DE1EIE_SEGNENT— deallocate  secon¬ 
dary  storage  and  reaove  the  appropriate  entry  froa  the  alias 
table  of  its  aentor  segaent.  The  six  Supervisor  entries 
into  the  Segaent  Manager  (viz.,  the  six  extended  instruc¬ 
tions)  will  be  discussed  individually  below.  The  PLZ/ASH 
listings  for  the  Segaent  Manager  are  in  Appendix  H. 
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i.  Cisats  a  Ssaiaai 

The  function  that  creates  a  segment  (i.e.,  adds  a  new 
segment  to  the  SASS)  is  CBEATE_SEGHEHT.  This  function  vali¬ 
dates  the  correctness  of  the  Supervisor  call  by  checking  the 
paraaeters  and  saking  certain  security  checks.  The  distri¬ 
buted  aeaory  aanager  is  then  called  to  accoaplish  interpro¬ 
cess  coaaunication  with  the  Memory  Manager  Process,  where 
segnent  creation  is  realized  through  secondary  storage  allo¬ 
cation  and  alias  table  updating. 

CBEATE_SEGHEHT  is  passed  as  arguaents:  (1)  Hen- 
tor_Seg_No--the  segment  number  of  the  mentor  segment  of  the 
segment  to  be  created,  (2)  Bntry_No — the  desired  entry  num¬ 
ber  in  the  alias  table  of  the  mentor  segment,  (3)  Class — the 
access  class  (label)  of  the  segment  to  be  created,  and  (4) 
Size — the  desired  size  of  the  segment  (in  blocks  of  256 
bytes) .  The  initial  check  is  to  verify  that  the  desired 
size  does  not  exceed  the  designed  maximum  segment  size.  If 
this  check  is  satisfactory,  a  conversion  of  the  Men- 
tor_Seg_Ho  to  a  KST  index  is  necessary.  This  is  because  the 
Kernel  segments  use  the  first  several  segment  numbers  avai¬ 
lable  but  do  not  have  entries  in  the  KST.  Thus  if  there 
were  10  Kernel  segments  and  a  system  segment  had  segment 
number  15,  then  its  index  in  the  KST  would  actually  be  5 
(i.e.,the  Kernel  segments  would  use  numbers  0-9,  and  this 
segment  would  be  the  sixth  segment  in  the  KST  and  its  index 
would  be  5) .  A  call  is  then  made  to  the  procedure 
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ITC_GET_SE3„PTR  with  the  constant  KST_SEG_MQ  passed  as  a 
paraaeter.  This  procedure  will  return  a  pointer  to  the  base 
of  this  process'  KST.  This  pointer  is  then  the  basis  for 
addressing  entries  in  the  KST.  The  next  check  is  to  see  if 
the  aentor  segment  is  known  (viz.,  is  in  the  address  space 
of  the  process,  and  thus,  in  the  KST) .  The  key  to  deterain- 
ing  if  any  segaent  is  known  is  the  aentor  segaent  entry 
(M_SEG_Ho)  for  that  segaent  i  the  KST.  If  not  known,  this 
entry  in  the  segaent's  KST  record  will  be  filled  with  the 
constant  tfdLL.SEG.  The  basis  for  checking  to  see  if  the 
segaent's  aentor  segaent  is  known  is  the  aliasing  scheae  in- 
plication  that  a  aentor  segment  aust  be  known  before  a  seg¬ 
aent  can  be  created.  The  process  classification  aust  next 
be  obtained  from  the  Traffic  Controller.  The  process  clas¬ 
sification  is  checked  to  ensure  that  it  is  equal  to  the 
classification  of  the  aentor  segment  since  write  access  to 
its  alias  table  is  needed  to  create  a  segaent.  The  NDS  mo¬ 
dule's  CLASS_EQ  procedure  is  called  and  returns  a  code  of 
true  or  false.  The  last  check  is  the  compatibility  check  to 
ensure  that  the  classification  of  the  segaent  to  be  created 
is  greater  than  or  equal  to  the  classification  of  the  aentor 
segaent.  This  is  accomplished  by  calling  the  NDS  module's 
CL ASS_GE  procedure  which  returns  a  code  of  true  or  false. 
If  any  of  these  checks  are  unsatisfactory,  an  appropriate 
error  code  is  generated  and  the  Segaent  manager  returns  to 
its  calling  point.  If  all  checks  are  satisfactory,  then  a 
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pointer  to  the  mentor  segment's  HM..Handle  array  is  derived 
(HPTR) .  Rote  that  in  the  current  memory  manager  design  [5] 
the  actual  MMJlandle  contents  are  a  Uaigue_lD  (a  long  word, 
viz.,  two  words  concatenated),  and  an  Indez.No  (index  into 
the  G_AST,  a  word) ;  thus  together  these  two  fields  are  a  to¬ 
tal  of  three  words.  Since  the  Segaent  Sanager  does  not  in¬ 
terpret  this  handle,  it  is  considered  a  three  word  array  at 
this  level.  For  this  reason,  the  entire  uninterpreted 
MM_Handle  array  will  be  passed  by  passing  its  pointer.  This 
pointer  and  Entry..  No,  Size,  and  Class  are  then  passed  in  a 
call  to  the  distributed  aeeory  eanager  procedure 
MM_CREATE_EHTHT .  This  procedure,  in  turn,  perforas  IPC  with 
the  aeaory  manager  process  where  segaent  creation  ultimately 
is  accomplished.  A  success  code  is  returned  in  an  IPC  mes¬ 
sage  from  the  aeaory  manager  process  via  the  distributed  ae¬ 
aory  aanager  to  the  CEElTEwSEGHEHT  procedure  to  indicate 
success  or  failure  as  appropriate.  This  success  code  is 
checked  by  the  Segsent  Manager  to  ensure  confinement  would 
not  be  violated  if  it  is  returned  to  the  calling  process' 
supervisor  domain.  Only  after  the  success  code  has  been  re¬ 
turned  can  the  action  of  segaent  creation  be  considered  coa- 
plete.  segaent  creation  does  not  iaply  the  ability  to  re¬ 
ference  that  segaent;  MAKB_KH0H1I  will  accomplish  that. 
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2 .  csls&s  a  Ssanal 

The  function  that  deletes  a  segment  (i.e. ,  deletes  a 
segment  from  SASS)  is  DELETE_SEGMEHT.  Validation  of  parame¬ 
ters  and  security  checks  are  performed  here  similar  to  (but 
fever  than)  the  CREATE_SEGMEHT  checks.  The  distributed  me¬ 
mory  manager  is  then  called  to  cause  1PC  vith  the  memory 
manager  process,  where  segment  deletion  is  realized  through 
secondary  storage  deallocation  and  alias  table  entry  dele¬ 
tions.  DELETE_SEGMENT  is  passed  as  arguments:  (1)  Hen- 
tor_Seg_No  and  (2)  Entry_No.  Conversion  of  the  Hen- 
tor_Seg_No  to  a  KST  index  is  accomplished  first.  The 
pointer  tc  the  base  of  the  KST  is  located  and  returned,  as 
before.  The  mentor  segment  is  checked  to  ensure  it  is 
known,  again,  by  verifying  that  its  own  fl_SEG_No  (mentor 
segment  number)  entry  in  the  KST  is  not  the  NOLL_SEG.  The 
process  classification  is  obtained  from  the  TC  and  checked 
(by  a  call  to  CLASS_EQ)  to  ensure  it  is  equal  to  the  mentor 
segment  classification,  since  deleting  an  entry  requires 
write  access  to  the  alias  table.  If  all  checks  are  satis¬ 
factory,  then  the  mentor  segment's  HH_aaadle  pointer  is  der¬ 
ived.  This  pointer  and  the  mentor  segment  alias  table  entry 
number  are  passed  in  a  call  to  the  distributed  aenory  manag¬ 
er  procedure  HM_DELETE_ENTBY.  It  then  performs  IPC  with  the 
memory  manager  process  where  segment  deletion  is  accom¬ 
plished  and  a  success  code  is  returned  as  before. 
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3.  sails  a  aaaiaal  flaasa 


The  function  that  lakes  a  segaent  known  (i.e.,  adds  that 
segaent  to  the  process*  address  space  by  assigning  a  segaent 
nuaber,  updating  the  KST,  and  causing  the  aeaory  aanager 
process  to  "activate1*  the  segaent  (that  is,  add  it  to  the 
AST  ))  is  BAKE_KNOHN.  Baking  a  segaent  known  is  the  way  the 
Supervisor  declares  its  intention  to  use  a  segaent. 
BAKE_KNOWN  is  passed  as  arguaents:  (1)  Bentor_Seg_No,  (2) 
Entry_No,  and  (3)  Acess_Desired  (e.g.,  write,  read,  or 
null) .  It  returns  (1)  a  success  code,  (2)  the  access  al¬ 
lowed  to  the  segaent,  and  (3)  the  segaent  nuaber.  Conver¬ 
sion  of  the  nentor  segaent  nuaber  to  a  KST  index,  finding 
the  KST  pointer,  and  verifying  that  the  aentor  segaent  is 
known  occur  as  previously  discussed. 

There  are  three  basic  cases  that  aay  occur  in 
NAKE.KNOHN:  (1)  the  segaent  is  already  known  (has  an  entry 
in  the  KST) ,  (2)  the  segaent  is  not  known  and  there  is  a 
segaent  nuaber  available,  or  (3)  the  segaent  is  not  known 
and  there  is  no  segaent  nuaber  available. 

A  search  is  aade  of  the  KST  using  each  record's  (seg- 
nent's)  B_SEG_No  (aentor  segaent  nuaber)  and  Entry _Nuaber 
fields  as  the  search  key.  If  these  two  fields  aatch  the  in¬ 
put  values  Hentor_Seg_No  and  Entry.No,  then  the  record  in¬ 
dexed  is  that  of  the  desired  segaent;  thus  the  segaent  to  be 
aade  known  is  already  known.  In  this  case,  all  that  need  be 
done  is  to  return  the  success  code,  segaent  nuaber  (convert- 
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ed  froa  the  index  by  addin?  to  it  the  nuaber  of  kernel  seg- 
■ents) ,  and  the  access  allowed  (equal  to  the  Access. Mode  en¬ 
try  in  the  KST  for  the  already  known  segaent) . 

During  the  search  of  the  KST,  the  M_SES.No  field  is  also 
checked  to  see  if  it  contains  the  MOU..SES  entry  (this  ia- 
plies  that  the  segaent  nuaber  associated  with  the  record  is 
"available") .  The  first  tiae  this  is  noted,  the  index  is 
saved.  Note  the  first  available  index  is  saved  since  it  is 
desired  to  assign  segaent  nuabers  at  the  "top"  of  the  KST  to 
keep  it  dense  there.  When  the  search  does  not  find  that  the 
segaent  is  already  known,  the  index  for  the  available  seg- 
aent  nuaber  is  retrieved  and  converted  to  segaent  nuaber  by 
adding  to  it  the  nuaber  of  kernel  segaents.  if  this  index 
is  the  NOLL.SEG  entry,  then  there  is  no  segaent  nuaber  avai¬ 
lable.  In  this  event,  the  success  code  is  set  to 
NO_SEG_AVAIL,  the  segaent  nuaber  is  assigned  NOLL.SEG,  and 
access  allowed  is  set  to  NULL.ACCESS  (this  is  the  third  case 
aentioned) .  if  the  index  is  not  equal  to  NO LL.SEG  and  con¬ 
version  to  segaent  nuaber  has  occurred  then  the  Traffic 
Controller  is  called  to  provide  the  DBB.No  (descriptor  base 
register  nuaber)  for  the  current  process.  The  DBB.No  is 
used  by  the  aeaory  aanager  process  as  an  index  in  the 
MHO.laage  and  the  local  AST.  The  distributed  aeaory  aanager 
procedure  HM.Activate  is  called;  it  is  passed  the  DBB  nua¬ 
ber,  the  pointer  to  the  aentor  segaent* s  MH.Handla  entry, 
the  aentor  segaent  alias  table  Entry.No,  and  the  segaent 
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nuaber.  SM_Activate  performs  the  normal  interface  function 
(performs  IPC  with  the  memory  manager  process  procedure  that 
updates  the  local  and  global  AST's)  and  also  updates  the  KST 
entry  for  the  new  segment's  HM_Handle  entry  (returned  from 
the  memory  manager  process) .  It  also  returns  to  the  Segment 
Manager  the  success  code*  the  segment  classification*  and 
the  segment  size  from  the  memory  manager  process.  If  the 
success  code  is  "succeeded"  then  the  issue  of  access  to  be 
granted  must  be  resolved.  The  process  classification  is  ob¬ 
tained  from  the  TC  and  passed  with  the  segment  classifica¬ 
tion  to  the  NOS  Module  procedure  CLASS  JIB.  If  the 
CONDITIOH.CODE  returned  is  FALSE  then  access  allowed  is 
NOLL.ACCESS,  the  segment  number  is  NULL.SEG*  and 
HH.DEACTIVATE  is  called  to  deactivate  the  segment.  An  appro¬ 
priate  error  code  is  returned.  If  it  is  greater  than  or 
equal  then  the  access  allowed  is  assigned  as  follows:  (1) 
the  two  classifications  are  compared  again — this  time  to  see 
if  equal;  (2)  If  they  are  equal*  then  the  access  allowed  is 
either  read  or  write  per  the  access  desired;  (3)  if  they  are 
not  equal  (i.e. *  the  process  class  is  greater  than  the  seg¬ 
ment  class)  then  the  access  allowed  is  read.  Finally  the 
KST  entries  for  that  segment  number  (more  accurately  for  its 
index  in  the  KST)  are  filled  with  the  appropriate  informa¬ 
tion  (e.g.*  IN_CORE  is  false*  etc.).  If  the  success  code 
returned  from  the  memory  manager  process  via  the  distributed 
memory  manager  is  not  "succeeded"*  then  the  segment  number 
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is  set  to  HU LL_SEG  and  the  access  allowed  is  set  to 
HULL_ACCESS. 

“•  aafca  a  Saaaaa*  gntoa«fl  (Untaatu 

The  function  that  makes  a  s eg sent  unknown  (i.e.,  removes 
that  segaent  froa  the  process'  address  space— by  updating 
the  KST  and  causing  the  aeaory  manager  process  to  "deacti¬ 
vate"  the  segaent)  is  TEHHIHATE.  It  results  in  reaoval  of 
the  H_SEG_No  (mentor  segaent  nuaber)  entry  froa  that  seg¬ 
ment*  s  KST  record.  Terainate  is  passed  the  segaent  nuaber 
of  the  segaent  to  be  terainated  as  an  argument.  It  returns 
a  success  cede.  Conversion  of  the  segaent  nuaber  to  a  KST 
index,  finding  the  KST  pointer,  and  verifying  that  the  seg¬ 
aent  is  known  occurs  in  the  saae  Banner  as  previously  dis¬ 
cussed.  The  next  check  is  to  verify  that  the  segaent  is  not 
still  loaded  in  the  process'  virtual  core  (viz.,  it  has  been 
"swapped-out") .  If  not,  an  error  code  is  returned  and  the 
user  aust  cause  the  Segment  Hanager  extended  instruction 
SM_SHAP_QUT  to  be  executed.  The  next  check  is  to  ensure 
that  the  user  is  not  atteapting  to  terainate  a  Kernel  seg¬ 
aent.  The  first  several  segaent  nuabers  in  a  process'  ad¬ 
dress  space  will  be  used  by  Kernel  procedures  and  data 
(though  they  will  not  be  entries  in  the  KST) .  Thus  if  there 
were  10  Kernel  segments,  then  the  segaent  nuaber  to  be  ter¬ 
ainated  aust  be  greater  than  or  equal  to  #10  (since  the  Ker¬ 
nel  segaents  used  #'s  0-9)  .  Thus  a  check  is  aade  to  ensure 


that  the  segaent  nuaber  is  not  less  than  the  nuaber  of  Ker¬ 
nel  segaents;  otherwise  an  error  code  is  returned.  Next, 
the  segaent  nuaber  is  checked  to  ensure  that  it  is  not  lar¬ 
ger  than  the  aaxiaua  segaent  nuaber  allowable  (if  so,  an  er¬ 
ror  code  is  returned) .  If  all  checks  are  satisfactory,  then 
the  segaent* s  Hfl_Handle  pointer  and  the  process  OBH.No  are 
obtained  (as  discussed  before)  and  passed  in  a  call  to  the 
BH_Deactivate  procedure.  It  calls  the  aeaory  aanager  pro¬ 
cess  procedure  DEACTIVATE  which  renowes  or  updates  (as  ap¬ 
propriate)  the  entries  in  the  local  and  global  AST's. 

s.  5sae  i  ssaiaai  la 

The  function  that  swaps  a  segaent  froa  secondary  storage 
to  sain  aeaory  (global  or  local)  is  SB_SHAP_IH.  It  is 
passed  the  segaent  nuaber  of  the  segaent  to  be  swapped  in  as 
an  arguaent  and  returns  a  success  code.  Conversion  of  the 
segaent  nuaber  to  a  KST  index,  finding  the  KST  pointer,  and 
verifying  that  the  segaent  nuaber  is  known  are  accoaplished 
as  previously  discussed.  If  the  check  is  satisfactory,  then 
the  segaent*s  8B_Handle  pointer  and  the  process  DBR  nuaber 
are  obtained.  They  are  passed  with  the  segaent's  access 
aode  (froa  the  KST)  as  arguaents  in  the  call  to  B3_SBAP_IN. 
It  perforas  noraal  interface  (IPC)  functions  and  returns  a 
success  code  froa  the  aeaory  aanager  process'  SHIP.IN  proce¬ 
dure  (where,  if  not  already  in  core,  allocation  of  aain  ae- 
oory  space  and  reading  the  segaent  into  aain  aeaory  occurs) . 
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If  the  success  code  is  "succeeded"  then  the  segment's 
I N_C0HB  entry  in  the  KST  is  updated  to  show  that  the  segment 
is  in  sain  aeaory  for  this  process  (i. e.,  the  entry  is  now 
"true")  . 

s»e  a  Ssaiaal  oat 

The  function  that  swaps  a  segaent  froa  aain  aeaory  to 
secondary  storage  is  sa_S8AP_OOT.  It  is  passed  the  segaent 
nuaber  of  the  segaent  to  be  swapped  out  as  an  arguaent  and 
returns  a  success  code.  The  behavior  of  sa.SUAP_OOT  is  ex¬ 
actly  analogous  to  that  of  SS_SHAP_IN  except  that  the  seg¬ 
ment's  KST  IN.COHE  entry  is  updated  to  reflect  that  the  seg¬ 
aent  has  been  reaoved  froa  aain  aeaory  for  this  process 
(i.e. ,  the  new  entry  is  "false"). 

c.  SSS26III  SfifiSU 

The  Non-Discretionary  Security  Bodule  iapleaents  the 
non-discretionary  security  policy  for  the  SASS.  The  NDS  ao- 
dule  contains  two  procedures:  CLASS_EQ  and  CLASSICS;  both 
coapare  two  labels  (classifications)  and  deteraine  if  their 
relationship  ae9ts  that  of  the  procedure's  naae  (i.e., 
equal,  or  greater  than  or  equal) .  Although  the  type  of 
checks  being  aade  are,  in  fact,  coapatibility  checks,  Siaple 
Security  Condition  checks,  etc,  the  NDS  Bodule  does  not  re¬ 
cognize  or  need  to  recognize  this.  It  siaply  uses  an  algor- 
itha  to  deteraine  if  classification  *1  *  classification  #2 
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or  if  classification  #1  >*  classification  #2,  as  appropri¬ 
ate.  It  then  returns  a  condition  code  of  true  or  false  in 
accordance  with  the  particular  case.  The  earlier  discussion 
of  label  coaparison  in  accordance  with  a  partially  ordered 
lattice  structure  is  relevant  in  discussing  the  MDS  Module's 
algoritha.  Consider  the  saie  "totally  ordered"  relationship 
TS  >  S  >  C  >  0  of  levels  and  the  "disjoint"  relationship  Cy 
I  N  |  Hu  |  %  of  categories.  Coaparison  of  levels  will  be 
nuaerical  coaparisons  while  coaparison  of  categories  will 
use  set  theory  coaparison  as  a  basis.  If  TS*4,  S*3,  C=*2,  0-1 
are  level  nuaerical  assignaents,  then  the  totally  ordered 
relationship  is  aaintained  (i.e.,  TS>S>C>U  is  still  true). 
How  consider  the  categories  and  sake  the  following  assign- 
aents:  Cy=1,  N=  2 ,  Hu=4,  *»0.  Hote  that  a  classification  nay 
have  only  one  level  and  one  category  set  (the  category  set 
nay  contain  several  categories) .  Consider  this  ezaaple: 

(TS,  Cy,N  .  The  level  is  TS  (*4) .  The  category  is  the  set 

Cy,H  and  nuaerically  is  foraed  by  perforaing  a  logical  OB 
with  the  categories  Cy  and  H.  Sixteen  bit  representation  of 
this  is: 
cy  OB  M 

(0000  0000  0000  0001)  OB  (0000  0000  0000  0010) 

*  0000  0000  0000  0011  *  Cy,H 

If  (TS,  Cy,N  )  is  considered  label  *1  and  (S,  H  )  as  label 
•2  then  a  coaparison  of  the  two  labels  would  be: 

(1)  Coapare  level  #1  with  level  #2  —  4  >  3? 

Clearly,  the  answer  is  yes. 
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(2)  Compare  category  #1  with  category  #2  —  is 
(0000  0000  0000  0011)  a  superset  o£ 

(0000  0000  0000  0010) ,  or  aore  clearly 
is  the  latter  a  subset  of  the  foraer? 

The  answer  is  yes,  and  one  way  to  show  that  is  true  is 
by  perforaing  a  logical  OR  of  category  #1  with  category  *2 
and  coaparing  the  result  to  category  *1.  If  the  result  of 
the  OS  operation  equals  category  #1  then  category  #1  is  a 
superset  (not  necessarily  proper)  of  category  #2.  Since  us¬ 
age  of  the  tera  subset  is  aore  frequent  than  that  of  super¬ 
set,  this  relationship  will  typically  be  stated  as  "category 
#2  is  a  subset  of  category  *1.  To  illustrate  the  above: 

Cy, N  OR  N  : 

(0000  0000  0000  0011)  OR  (0000  0000  0000  0010) 

*  0000  0000  0000  0011  a  category  #1. 

This  aeans  ,  in  this  ezaaple,  that  category  #2  is  a  sub¬ 
set  (not  necessarily  proper)  of  category  *1.  Since  level  #1 

>  level  *2  and  category  #2  subset  category  >1  then  label  #1 

>  label  *2.  Thus,  a  call  to  the  CLASS_EQ  procedure  with 
these  two  labels  as  the  input  classifications  would  return  a 
condition  code  of  false  while  CLASS_GE  would  return  true. 
The  decision  to  have  the  classifications  as  long  word  (32 
bits)  supports  the  requirement  of  soae  DoD  specifications 
for  eight  levels  and  sixteen  categories.  This  sodule  uses 
sixteen  bits  for  the  level  and  sixteen  bits  for  the  catego¬ 
ry.  Appendix  I  is  the  PLZ/ASB  listings  for  the  HDS  Module. 
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1-  £92141  £l4Sli£l£4lifiA  &SS& 

The  CL&SS.EQ  procedure  perforas  coeparison  of  two  clas¬ 
sifications  (labels)  and  returns  a  condition  code  of  true  if 
they  are  equal  (an  exact  natch  of  the  two  long  words  bit  per 
bit)  or  false  if  they  are  not. 

2.  SES4&3C  fi£  £9941  Slftilit lff4tl9B  SfeiSiL 

The  CL&SS.SE  procedure  perforns  coeparison  of  two  clas¬ 
sifications  (labels)  and  returns  a  condition  code  true  if 
classification  #1  is  greater  than  or  equal  to  classification 
#2  or  a  condition  code  of  false  otherwise.  For  classifica¬ 
tion  #1  to  be  greater  than  or  equal  to  classification  #2, 
the  following  nust  be  true:  (1)  level  #1  >=  level  *2  (deter¬ 
mine  this  by  sinple  nuaerical  coeparison  of  values)  and  (2) 
category  *2  subset  category  *1  (deteraine  this  by  per forcing 
a  logical  OB  with  the  categories  and  coeparing  the  result  to 
category  il  —  if  they  are  equal  then  category  *2  is  a  sub¬ 
set  of  category  #1)  . 

Since  PLZ/SYS  allows  passing  only  "simple"  types  in 
calls,  the  labels  were  passed  as  long  words  (as  opposed  to 
each  being  word  arrays  of  length  two) .  In  access  class  label 
is  never  interpreted  outside  the  HDS  Module.  However,  with¬ 
in  the  NDS  Module  it  is  necessary  to  address  the  classifica¬ 
tion's  conponents  separately  (viz.,  level  and  category). 
Thus,  an  "overlay"  of  the  logical  view  of  the  classification 
was  created.  This  overlay  was  a  record  of  type  ACCESS_CL4SS 
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and  it  consisted  of  two  fields:  level  —  16  bit  integer  and 
category  —  16  bit  integer.  &  pointer  type  CPTB  was  declared 
to  be  of  type  pointer  to  ACCESS_CLASS.  Two  other  pointers 
CLASS1_PT8  and  CLASS 2_PTB  were  declared  to  be  of  type  CPTB 
and  were  set  equal  to  the  base  address  of  CL ASS 1  and  CLASS2 
respectively.  This  "overlay1*  of  the  record  fraae  over  the 
two  classification  labels  passed  as  arguments  allowed  the 
desired  component  addressibility.  Puthermore,  the  non-dis- 
cretionary  policy  enforced  by  SASS  can  be  changed  froa  the 
current  DoD  policy  to  another  lattice  policy  by  changing 
(only)  the  MDS  Module. 

d.  fiisisieam  MEMORY  H1NAGEB  aODOLE 

The  Distributed  Heaory  Manager  Module  perforas  as  an  in¬ 
terface  between  the  Segment  Manager  and  the  Memory  Manager 
Process.  As  its  name  implies,  it  is  distributed  in  the  ker¬ 
nel  domain  of  each  Supervisor  process.  The  key  role  per¬ 
formed  in  this  nodule  is  to  arrange  and  perform  interprocess 
coaaunication  between  its  process  (actually  the  VP)  and  the 
aeaory  manager  process  (YP).  The  aodule  consists  of  eight 
procedures.  Six  of  the  procedures  are  called  directly  by 
Segment  Manager  procedures;  they  ace  MM_CBEATE_ENTBY , 
MK_DELETE_SMTBI,  MM_ACTI YATE,  MM_DE ACTIVATE,  MM_SMAP..IN,  and 
MM_S«AP_OOT.  The  other  two  procedures  are  "service"  proce¬ 
dures  called  by  multiple  procedures;  they  are: 
HM_GET_DBB„VALOE  and  PEHFORH_IPC.  The  logic  used  in  the 
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first  six  procedures  is  soaewhat  unifors  (except  for 
MH_ ACTIVATE) .  Thus,  the  general  logic  will  be  explained 
(vith  aa_CR2ATE_BMTHT  as  an  exaaple)  and  it  should  suffice 
as  a  description  for  all  (except  BM.ACTIVAIE)  procedures. 
The  service  procedures  will  be  described  separately. 


1.  SasSCiB&iSA  2 I  Procedures 

Each  procedure  is  invoiced  (and  returns)  on  a  one  to  one 
basis  with  a  corresponding  procedure  in  the  Segaent  Manager. 
For  exaaple,  CHEAT B.SEGMENT  invoices  MB.CBE ATE.ENTHI  which 
signals  the  CHEATE.ENTHY  procedure  in  the  aenory  Manager 
Process  Module.  Associated  with  each  procedure  is  an  IPC 
aessage  "fraae"  to  describe  the  unique  foraat  of  the  con¬ 
tents  of  the  aessage  to  be  signalled  to  the  aeaory  aanager 
process.  Siailarly,  there  aust  be  a  aessage  "fraae"  for  re¬ 
turn  aessages  froa  the  aeaory  aanager  process;  this  fraae  is 
the  saae  for  all  but  the  aa_ACTI?ATE  procedure.  Consider  the 
aessage  fraae  for  BB.CBEATB.SHTBI ;  it  consists  of:  (1)  a 
code  to  describe  which  function  is  to  be  perforaed  (e.g., 
CBEAT E_CODB  indicates  that  the  caEATE.SNTHY  procedure  is  the 
intended  recipient  of  the  aessage),  (2)  HM_Handle  (an  array 
of  three  words)  ,  (3)  Entry. Bo,  (4)  size,  and  (5)  Class.  The 
aessage  fraae  has  a  filler  (in  this  case)  of  one  byte  to  en¬ 
sure  that  it  is  of  length  16  bytes.  The  purpose  of  this 
fraae  is  to  provide  an  overlay  onto  the  actual  aessage  array 
to  be  signalled  and  to  facilitate  loading  the  arguaents  into 
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the  aessage  array.  This  is  accoaplished  by  having  a  pointer 
of  the  type  that  points  to  the  fraae  but  by  converting  its 
address  so  that  it  actually  points  to  the  base  of  the  aes¬ 
sage  array.  Consider  these  lines  of  PLZ/STS  code: 

CE_HSGPTfi  :*  CE_PT8  COH_MSGPTR 
CE_HSGPTB->.CBEATE_CODE  :=  C2E ATE_ERTRY_CODE 
This  code  is  putting  a  value  into  the  structure  pointed  to 
by  CE_SSGPTH  at  entry  CBEATE_CODE.  The  hey  point  is  that 
the  fraae  of  that  structure  is,  in  fact,  CREATB_HSG  (as  de¬ 
scribed  before) ,  but  the  physical  location  pointed  to  is  the 
aessage  array.  This  is  assured  by  having  the  pointer 
CE_HSGPTB  (which  points  to  a  structure  of  type  C£EATE_HSG) 
set  equal  to  a  pointer  (COM_HSGPTB)  to  the  actual  aessage 
array  (C08_aSGB0F) .  This  is  accoaplished  by  the  first  line 
of  code.  The  message  array  itself  is  never  directly  refer¬ 
enced,  but  rather  the  aessage  array  that  is  overlayed  by  the 
message  fraae  is  filled  in  the  format  of  the  CBEATE_MSG 
frame.  In  this  exaaple,  the  first  two  bytes  of  the  aessage 
array  now  contain  the  value  of  the  constant 
CREATB_EHTBI_CODE .  The  remainder  of  the  message  array  is 
filled  in  the  sane  aanner  (all  procedures  use  the  saae  no¬ 
tion  of  a  fraae,  although  the  fraaes  have  different  for¬ 
mats)  .  The  PEBFOBH.IPC  (perform  interprocess  coaaunication) 
procedure  is  called  by  all  procedures  at  this  point  in  their 
execution.  The  hey  is  that  the  arguaent  passed  is  the  aes¬ 
sage  array  pointer  not  the  pointer  to  the  CfiEATE_ESG  record 
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(after  all  it  is  only  an  overlay  fraae  —  linguistically,  it 
is  only  a  type  and  is  never  declared  as  a  structure  requir¬ 
ing  aeaory  storage  allocation) .  Hhen  PEBFQBM_IPC  returns, 
the  aessage  array  contains  a  return  aessage.  This  aessage 
consists  of  only  a  success  code  and  filler  space  in  all  cas¬ 
es  but  atl. ACTIVATE.  Interpretation  of  the  return  aessage  is 
perforaed  in  the  sane  aanner  as  loading  the  aessage  array. 
The  retrieved  success  code  is  returned  to  the  calling  Seg- 
aent  Manager  procedure.  For  NM_ACTIVAIE,  the  return  aessage 
aust  be  interpreted  and  values  for  success  code,  segaent 
size,  and  segaent  classification  retrieved  and  returned  to 
the  Segaent  Manager  MAKE_KMOBN  procedure.  The  value  for  the 
MM_Handle  (called  the  G_AST_Handle  by  the  aeaory  aanager 
process)  aust  be  retrieved  and  entered  in  the  KST  record  for 
this  segaent. 

2.  la&acstasass  SfliianisaUaa 

The  final  arrangeaents  and  actual  perfocaance  of  IPC  is 
coapleted  by  the  internal  procedure  PEBFOBM_IPC.  By  locating 
the  identity  of  the  current  physical  processor  (CPU)  and  us¬ 
ing  that  identity  to  index  into  the  MM_CPU_TABLE,  the  FP_I D 
of  the  current  aeaory  aanager  is  resolved,  so  that  the  aeao¬ 
ry  aanager  process  dedicated  to  this  physical  processor  is 
signalled.  The  call  to  K_LOCK  is,  in  fact,  a  disguised  call 
to  the  SPIN_LOCK  procedure  (since  K_LOCK  calls  SPIN_LOCK) . 
K_LOCK  represents  an  ultimate  (as  yet  uniapleaented)  goal  of 
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a  Kernel  lacking  (wait-lock)  system.  In  any  event,  the 
G_iST  lock  aust  be  set  prior  to  signalling  the  memory  manag¬ 
er  process.  After  SIGNAL  has  been  called,  a  call  is  aade  to 
9 AIT  with  the  pointer  to  the  nessage  array  as  the  argument. 
The  synchronization  cycle  that  results  is:  (1)  PERFOaa_IPC 
calls  the  ITC  procedure  SIGNAL  with  the  aeaory  manager  VP_ID 
and  message  array  pointer  as  arguments;  PEBPQ&&_IPC  then 
calls  9AIT  with  the  nessage  array  as  the  argument,  (2) 
SIGNAL  causes  the  message  array  to  be  copied  into  the  mes¬ 
sage  queue  (in  the  VPT)  of  the  appropriate  VP_ID,  (3)  ulti¬ 
mately,  the  signalled  VP  is  scheduled;  it  had  previously 
called  HAIT,  passing  a  pointer  to  its  own  local  message  ar¬ 
ray;  the  action  of  BAIT  is  to  copy  the  message  from  the  VPT 
to  the  signalled  process*  local  message  array;  there  it  is 
interpreted  by  the  memory  manager  process  main  procedure  and 
the  appropriate  procedure  is  called  for  action  (e.g., 
CHEATE_ENTRY) ,  (4)  when  action  is  completed  the  memory  man¬ 
ager  process  fills  its  local  message  array  with  the  appro¬ 
priate  return  message  and  calls  SIGNAL  with  a  pointer  to  the 
message  and  the  original  signalling  process'  YP„ID  as  argu¬ 
ments,  (5)  SIGNAL  causes  the  aeaory  manager  process'  message 
to  be  copied  into  the  VPT  message  queue  for  the  appropriate 
VP_ID,  (6)  that  VP  is  eventually  scheduled  and  through  the 
action  of  NAIT  has  the  return  message  copied  from  its  mes¬ 
sage  queue  in  the  VPT  to  its  local  message  array;  BAIT  then 
returns  to  P SB FORE  IPC.  The  G  AST  lock  is  unlocked  and 
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PEBFOHH_IPC  returns  to  the  appropriate  distributed  memory 
manager  procedure. 

The  last  procedure  in  the  distributed  aeeory  aanager  is 
BB_GET_DBB_7ALaz.  This  procedure  siaply  provides  the  ser¬ 
vice  of  translating  a  DBB_SO  (DBB  number)  into  its  appropri¬ 
ate  OBB  address.  It  is  called  by  the  TC_GETHOBK  procedure  to 
allov  it  to  call  the  ITC  procedure  SB1P_?DBB  (reaeaber  that 
presently  the  Inner  Traffic  Controller  deals  with  the  OBB  as 
the  address  of  the  appropriate  BBO  record  in  the  8BII_IBAGB 
while  the  Traffic  Controller  uses  DBB  as  a  OBB  nuaber  which 
indexes  to  the  appropriate  BBU  record) . 

e.  5258481 

The  iapleaentation  of  segaent  aanageaent  functions  and  a 
non-discretionary  security  policy  for  the  SASS  has  been  pre¬ 
sented  in  this  chapter.  The  iapleaentation  of  the  Segaent 
Manager  Module,  Bon- Discretionary  Security  Bodule,  and  Dis¬ 
tributed  Meaory  Manager  aanageaent  demonstration  was  de¬ 
scribed. 
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Chapter  XIX 

CONCLOSIOIS  AID  FOllOH  OH  HOfiK 
The  implementation  of  segaent  management  for  the  securi¬ 
ty  kernel  of  a  secure  archival  storage  system  has  been  pre¬ 
sented.  The  implementation  was  completed  on  Zilog's  Z8002 
sixteen  bit  nonsegaented  microprocessor.  Segmentation  hard¬ 
ware  (Zilog's  Z80 1 0  Memory  Management  Unit)  was  not  availa¬ 
ble,  therefore  it  was  simulated  in  software  as  described  by 
Reitz  [12].  The  loop  free  modular  construction  used  in  the 
iapleaentation  facilitates  ease  of  expansion  or  modifica¬ 
tion. 

A  non-discretionary  security  policy  was  implemented  us¬ 
ing  a  partially  ordered  lattice  structure  as  a  basis.  En¬ 
forcement  was  realized  through  an  algorithm  that  compared 
two  labels  and  determined  if  their  relationship  was  egual  to 
a  desired  relationship.  Although  the  OoO  security  classifi¬ 
cation  system  was  represented,  any  non-discretionary  securi¬ 
ty  policy  that  may  be  represented  by  a  lattice  structure  may 
similarly  be  implemented.  This  implementation  has  shown  that 
by  having  the  non-discretionary  security  policy  enforced  in 
one  module,  changing  to  another  policy  requires  changing 
only  this  one  module. 
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Software  engineering  techniques  used  in  previous  work 
emphasized  the  advantages  of  working  with  code  that  is  well 
structured,  well  docuaented,  and  well  organized.  Despite  be¬ 
ing  written  in  assembly  language,  Seitz*  inplesentation  of 
■ultiprograssing  and  process  sanageaent  proved  to  be  consis¬ 
tent  in  style,  clarity  and  do cu sent at ion.  This  enhanced  the 
construction  of  a  segaent  aanageaent  demonstration  which  was 
built  onto  his  synchronization  deaonstration.  Further,  re¬ 
finements  made  to  his  code  (not  necessitated  by  any  failures 
of  his  code)  were  relatively  easily  accomplished. 

While  the  segaent  aanageaent  iapleaentation  appears  to 
perfora  properly,  it  has  not  been  subjected  to  a  foraal  test 
plan.  Such  a  test  plan  should  be  developed  and  iapleaented. 

The  Heaory  Manager  Process  has  been  designed  but  not  im- 
pleaented.  segaent  aanageaent  iapleaentation,  provision  for 
IPC  using  more  practical  size  aessages,  and  the  detailed  de¬ 
sign  of  the  aeaory  aanager  by  Hoore  and  Gary  £5],  provide  a 
sound  foundation  for  aeaory  aanager  iapleaentation.  k  frame¬ 
work  of  the  mainline  code  needed  is  provided  in  the  Heaory 
Hanager  Module  of  the  deaonstration  code  in  Appendix  J.  Pri¬ 
or  to  this  iapleaentation,  forsal  testing  of  the  segaent 
aanageaent  iapleaentation  herein  and  the  aonitor  iapleaented 
by  Reitz  [12]  should  be  coapleted. 
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PART  r 

IHPLBHENTATIOH  OP  PROCESS  HAMAGBHBNT  FOR  A 
SECORB  ARCHIVAL  STORAGE  SISTEH 


This  section  contains  excerpts  froa  a  Naval  Postgraduate 
school  HS  Thesis  by  A.  R.  Strickler  [19].  The  origins  of 
these  excerpts  are: 

INTRODUCTION  froa  Chapter  I 
I NPL EH ENT AT ION  ISSUES  f r OB  Chapter  III 
PROCESS  HANAGEHENT  I MPLEHENTATION  froa  Chapter  IV 
CONCLUSION  froa  Chapter  v 

Hinor  changes  have  been  aade  for  integration  into  this  report. 


Chapter  ZZ 
IITBODOCTIOH 

This  thesis  addresses  the  iapleaentation  of  process  aan- 
ageeerrt  functions  for  the  Secure  Archival  Storage  Systea  or 
SASS.  This  systea  is  designed  to  provide  aultilevel  secure 
access  to  inforaation  stored  for  a  network  of  possibly  dis- 
siailar  host  coaputer  systeas  and  the  controlled  sharing  of 
data  aaongst  authorized  users  of  the  SASS.  Effective  pro¬ 
cess  aanageaent  is  essential  to  insure  efficient  use  and 
control  of  the  systea. 

The  aajor  accoaplishaents  of  this  thesis  effort  include 
the  provisions  for  efficient  process  creation  and  aanage¬ 
aent.  These  functions  are  provided  through  the  establish- 
aent  of  a  systea  Traffic  Controller  and  the  creation  of  a 
virtual  interrupt  structure.  An  effective  aechanisa  for  in¬ 
ter-process  coaaunication  and  synchronization  is  realized 
through  an  Event  Hanager  that  aakes  use  of  uniquely  identi¬ 
fied  segaents  supported  by  eventcount  and  sequencer  priai- 
tives.  A  hardware  controlled  two  doaain  operational  envi- 
ronaent  is  created  with  the  necessary  interfacing  between 
doaains  provided  by  a  software  "gate"  aechanisa.  Additional 
support  is  provided  through  considerable  work  in  the  area  of 
database  initialization  and  a  technique  for  liaited  dynaaic 
aeaory  allocation. 
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This  iapleaentation  was  coapleted  on  the  coaaercial  ABC 
Aa96/4116  SonoBoard  Coaputer  with  a  standard  Multibus  inter¬ 
face. 
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Chapter  ZZI 
I HPLEBE1TATI0M  ISSOBS 

Issues  bearing  on  the  implementation  o £  process  manage¬ 
ment  and  refinements  made  to  existing  modules  are  presented 
in  this  chapter.  Process  management  for  the  SASS  was  pro¬ 
vided  through  the  implementation  of  the  Traffic  controller 
Module,  the  Event  Manager  Module,  the  Distributed  Memory 
Manager  Module,  and  a  Gate  Keeper  Stub  (system  trap).  Addi¬ 
tionally,  since  a  demonstration/testbed  was  integral  to  the 
testing  and  verification  of  the  implementation,  it  was  ne¬ 
cessary  to  complete  other  supportive  tasks.  These  suppor¬ 
tive  tasks  included  limited  Kernel  database  initialization, 
revised  preempt  interrupt  handling  mechanisms,  idle  process 
definition  and  structure,  and  additional  refinements  to  ex¬ 
isting  modules. 

i.  fimaiss  imiAumiQ)? 

Previous  work  on  SASS  has  relied  on  statically  built  da¬ 
tabases,  which  proved  to  be  sufficient  for  demonstration  of 
a  single  processor,  single  host  supported  system.  In  the 
current  demonstration,  multiple  hosts  are  simulated,  and  the 
Kernel  data  structures  have  been  refined  to  represent  a  mul¬ 
tiprocessor  environment.  Since  a  multiprocessor  system  was 
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unavailable  at  the  time  of  this  demonstration,  several 
"runs'*  vere  aade  and  traced,  using  different  logical  CPU 
numbers,  to  shov  the  correctness  of  this  structure.  Due  to 
this  aultiprocessor  representation  and  simulation  of  multi¬ 
ple  hosts,  the  use  of  statically  built  Kernel  databases  uas 
no  longer  convenient.  Therefore,  it  became  necessary  to 
provide  initialization  routines  for  the  dynamic  creation  of 
those  Kernel  databases  required  for  this  implementation. 
While  it  uas  not  the  intent  of  this  effort  to  implement  sys¬ 
tem  initialization,  care  uas  taken  in  the  ariting  of  these 
initializing  routines  so  that  they  might  be  utilized  in  the 
system  intialization  implementation  uith,  hopefully,  minimal 
refinement.  Database  initialization  was  restricted  to  those 
databases  existing  in  the  Inner  Traffic  Controller  and  the 
Traffic  Controller.  Limited  elements  of  the  Known  Segment 
Table  (KST)  and  Global  lctive  Segment  Table  (G_AST)  were 
also  created  for  demonstration  purposes. 

i.  laasc  xiafiiis  Sfla&salltt  laiiialimian 

A  "Bootstrap  Loader"  Bodule,  which  logically  exists  at  a 
higher  level  of  abstraction  within  the  Kernel,  was  created 
to  initialize  the  databases  of  the  Inner  Traffic  Controller. 
This  initialization  includes  the  creation  of:  1)  the  Pro¬ 
cessor  Data  Segment  (PBDS) ,  2)  an  HHU  Hap,  3)  Kernel  domain 
stack  segments  for  Kernel  processes,  4)  allocation  and  up¬ 
dating  of  HHU  entries  for  Kernel  processes,  and  5)  Virtual 
Processor  Table  (VPT)  entries. 
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The  PRDS  was  loaded  with  constant  values  that  specify 
the  physical  CPU  ID,  logical  CPU  ID,  and  nuaber  of  TP's  al¬ 
located  to  the  CPU.  A  design  decision  was  aade  to  allocate 
logical  CPU  ID's  in  increaents  of  two  (beginning  with  zero) 
so  that  they  coaid  be  used  to  directly  access  lists  indexed 
by  CPU  nuaber.  The  HHU  aap,  constructed  as  a  "byte"  nap, 
was  created  to  specify  allocated  and  free  HHU  Iaage  entries. 

k  separate  procedure,  CREATE_STACK,  was  created  to  es¬ 
tablish  the  initial  Kernel  doaain  stack  conditions  for  Ker¬ 
nel  processes.  &  discussion  and  diagraa  of  these  initial 
stack  conditions  is  presented  in  the  next  section. 
ALLOCATE_HHU  checks  the  MHU  Hap  and  allocates  the  next 
availabe  HHU  entry  to  the  process  being  created.  The  PRDS 
is  inserted  in  the  allocated  HHU  entry  and  the  DBB  nunber  is 
returned  to  the  calling  procedure.  The  DBR  nuaber  (handle) 
is  aerely  the  offset  of  the  DBR  in  the  HHU  iaage.  since  the 
ITC  deals  with  an  address  rather  than  a  handle,  a  procedure, 
GET_DBR_ADDR,  was  created  to  convert  this  offset  into  a  phy¬ 
sical  address.  UPDATE_HHU..IHAGE  is  the  procedure  which 
creates  or  aodifies  HHU  Iaage  entries.  UPDATE.HHU.IHAGE  ac¬ 
cepts  as  arguaents  the  DBR  nuaber,  segaent  nuaber,  segaent 
attributes,  and  segaent  liaits.  To  facilitate  process 
switching  and  control,  various  process  segaents  aust  possess 
the  saae  segaent  nuaber  systea  wide.  This  is  accoaplished 
during  initialization  through  the  use  of  the 
UPDATE_HHU_IHAGE  procedure.  In  the  ITC,  these  segaents  in- 
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elude  the  PSDS  (segment  number  zero)  and  the  Kernel  stack 
segaent  (segment  nuaber  one) . 

The  final  task  required  in  ZTC  intialization  is  the 
creation  of  the  VPT.  The  VPT  header  is  initialized  with  the 
"running*  and  "ready"  lists  pointers  set  to  a  'nil*  state, 
and  the  "free"  list  pointer  set  to  the  first  entry  in  the 
message  table.  Virtual  Processor  entries  are  inserted  in 
the  main  body  of  the  VPT  by  the  UPDAIE_VP_1ABLE  procedure. 
Entries  are  first  made  for  the  VP's  permanently  bound  to  the 
Memory  Manager  and  Idle  processes.  The  VP  bound  to  the  MM 
process  is  given  a  priority  of  2  (highest) ,  and  the  VP  bound 
to  the  Idle  process  is  given  a  priority  of  0  (lowest) .  The 
External  VP  ID  for  both  of  these  VP's  is  set  to  “nil"  as 
they  are  not  visible  to  the  Traffic  Controller.  The  remain¬ 
ing  VP's  allocated  to  the  CP0  (viz.,  TC  visible  VP's)  are 
then  entered  in  the  VPT  with  a  priority  of  1  (intermediate) , 
and  their  "idle"  and  "preempt"  flags  are  set.  The  preempt 
flag  is  set  for  these  TC  visible  VP's  to  insure  proper  sche¬ 
duling  by  the  Traffic  Controller.  The  DBR  for  these  remain¬ 
ing  VP's  is  initialized  with  the  Idle  process  DBB.  A  dis¬ 
cussion  of  "idle"  processes  and  VP's  will  be  provided  later 
in  this  chapter.  The  External  VP  ID  for  each  TC  visible  VP 
is  merely  the  offset  of  the  next  available  entry  in  tne 
EXTERN Ah  VP  LIST.  This  External  VP  ID  is  entered  in  the 
VPT,  and  the  corresponding  VP  ID  (viz.,  VPT  Entry  #)  is  en¬ 
tered  in  the  EXTERNAL  VP  LIST. 
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Once  these  VPT  entries  have  been  made,  it  is  necessary 
to  set  the  state  of  each  VP  to  "ready"  and  thread  then  (by 


priority)  into  the  appropriate  ready  list.  &  VPT  threading 
aechanisa  was  provided  by  Reitz  [12]  in  procedure 
MAKE.READy .  However,  it  was  desired  to  have  a  aore  general 
threading  aechanisa  that  could  be  used  for  other  lists. 
Procedure  LIST_INSEBT  was  created  to  provide  this  general 
threading  aechanisa.  LIST_IHSERT  is  logically  a  "library" 
function  that  exists  at  the  lowest  level  of  abstraction  in 
the  Kernel.  This  function  threads  an  object  into  a  list 
(specified  by  the  caller)  in  order  of  priority,  and  then 
sets  its  state  as  specified  by  the  calling  paraaeters. 

Once  the  "Bootstrap  Loader"  has  completed  ITC  initiali¬ 
zation,  it  passes  control  to  the  ITC  GETBORK  procedure  to 
begin  VP  scheduling. 

2.  leaf  £  is  csatiailat  ifliiialiiaiias 

The  initialization  routines  for  the  ic  include  TC_INIT, 
CREATE_PROCESS,  and  CREAT £_KST .  These  routines  are  called 
froa  the  Memory  Manager  process.  The  MB  process  was  chosen 
to  initiate  these  routines  as  it  is  bound  to  the  highest 
priority  VP  and  will  begin  running  iaaediately  after  the  In¬ 
ner  Traffic  Controller  is  initialized.  Procedure 
HH_ ALLOCATE  was  written  to  allocate  aeaory  space  for  data 
structures  during  initialization  (viz..  Kernel  stacks,  user 
stacks,  and  KST's) .  Memory  space  is  allocated  in  blocks  of 
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100  (hex)  bytes.  MH_ALLOCATE  is  merely  a  stub  of  the  memory 
allocating  procedure  designed  by  Hcore  and  Gary  C53« 

It  u<s.  necessary  to  pass  long  lists  of  arguaents  to  the 
TC  for  initialization  purposes.  To  aid  in  this  passing  of 
paraaeters,  a  data  structure  template  was  used.  This  taap- 
late  vas  created  by  declaring  the  paraaeters  as  a  data 
structure  in  both  the  sending  and  receiving  procedures*  and 
then  iaaging  this  structure  at  absolute  address  zero.  The 
process'  stack  pointer  was  then  decreaented  by  the  size  of 
the  parameter  data  structure*  and  the  paraaeters  were  loaded 
into  this  data  structure  indexed  by  the  stack  pointer.  This 
teapLate  made  it  very  easy  to  send  and  receive  long  argument 
lists  using  the  process'  stack  segment. 

TC_INIT  initializes  the  APT  header  and  virtual  interrupt 
vector  (discussed  later) .  Each  element  of  the  running  list 
is  marked  "idle",  the  ready  and  blocked  lists  are  set  to 
"nil",  and  the  number  of  VP* s  and  first  VP  for  eacn  CPU  are 
entered  in  the  VP  table.  The  address  of  the  virtual  preempt 
handler  is  then  passed  to  the  ITC  procedure  CRE ATE_INT_VEC 
for  insertion  in  the  virtual  interrupt  vector. 

CR£ATE_PBOC ESS  intializes  user  processes  and  creates  en¬ 
tries  in  the  APT.  ALLOCATE.tieO  is  called  to  acquire  a  DBR 
number*  and  an  APT  entry  is  created  with  the  process  de¬ 
scriptors  (viz.*  paraaeters).  The  process  is  then  declared 
"ready"  and  tar,  -led  into  the  approciate  ready  list  by 
calling  the  threading  function*  LIST_INSEET.  A  user  stack 
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is  allocated  and  OP DAT E_MHU_ IMAGE  is  called  to  include  the 
user  stack  in  the  8HU  as  segment  number  three.  The  user 
stack  contains  no  information  or  user  process  initialization 
parameters  (viz.,  execution  point  and  address  space)  as  all 
processes  are  initialized  and  begin  execution  from  the  Ker¬ 
nel  domain.  Next,  a  Kernel  domain  stack  is  allocated  and 
included  in  the  MMU  Image.  A  design  decision  was  made  to 
initialize  the  Kernel  stacks  for  user  processes  with  the 
same  structure  as  the  Kernel  process*  stacks.  The  rationale 
for  this  decision  is  presented  in  the  next  section.  As  a 
result  of  this  decision#  it  became  possible  to  use  the 
CREATE_STACK  procedure  in  building  Kernel  domain  stacks  for 
both  Kernel  and  user  prosesses.  CREATE_STACK  was  therefore 
used  as  a  library  function  and  placed  in  the  library  module 
with  LIST-IHSERT. 

Finally,  a  Known  Segaent  Table  (KST)  stub  is  created  to 
provide  a  means  of  demonstrating  the  mechanism  provided  by 
the  eventcounts  and  sequencers  for  interprocess  communica¬ 
tion  (IPC)  and  mutual  exclusion.  Space  for  the  process'  KST 
is  created  by  calling  HH_ALLOCATE.  The  KST  is  then  included 
in  the  process'  address  space,  as  segaent  number  two,  by 
tJPDATE_dHU .IHAGE.  Initial  entries  are  made  in  the  Known 
Segment  Table  by  procedure  C5EATE_KST.  CREATE_KST  makes  an 
entry  in  the  KST  for  the  "root"  and  narks  the  remaining  KST 
entries  as  "available."  The  Onigue_ID  portion  of  the  root's 
handle  (viz.,  upper  two  words)  is  initialized  as  -1  (for 
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convenience)  and  the  G_ASX  entry  number  portion  o£  the  han¬ 
dle  (viz.,  lowest  word)  is  initialized  with  zero. 

3.  Addi&is&al  ipitiallzatiQB  fisaaiisiaass 

As  already  mentioned,  the  Memory  Manager  Process  prepares 
the  arguaents  utilized  by  TC_INIT,  CBE1IE_PR0CESS,  and 
C8EATE_K3T  for  TC  initialization  and  user  process  creation. 
Additionally,  the  ME  process  creates  a  Global  Active  Segaent 
Table  (G_AST)  stub  utilized  fcr  demonstration  of  event  data 
management.  The  G_1ST  stub  is  declared  in  a  separate  module 
(viz.,  the  DEHO_DAXABASE  Module)  with  the  format  prescribed 
by  Moore  and  Gary  [5].  However,  the  only  fields  initialized 
and  utilized  by  this  implementation  are  UNIQUE_ID, 
SEQUENCES,  INSTANCE  1,  and  INSTANCE  2.  The  eventcounts  and 
sequencer  fields  are  initialized  as  zero  whenever  an  entry 
is  created  in  the  G_AST.  The  UNIQUE_ID  is  created  just  to 
support  this  demonstration  and  does  not  reflect  the  seg¬ 
ment's  unique  identifier  as  specified  by  Moore  and  Gary  [5]. 
In  this  demonstration,  UNIQUE_ID  is  built  with  the  parame¬ 
ters  passed  to  MM_ACTIVATK.  The  first  word  in  UNIQUE_ID  is 
the  G_AST  entry  number  of  the  segment's  parent,  and  the  sec¬ 
ond  word  is  the  segment's  entry  number  into  the  alias  table. 
The  UNIQUE.IO  together  with  the  offset  of  the  segment's  en¬ 
try  in  the  G_AST  comprise  the  segment  HANDLE  maintained  in 
the  KST .  The  first  entry  in  the  G_AST  is  reserved  for  the 
root,  and  is  initialized  with  an  Unigue_ID  of  minus  one 
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(-1).  It  should  be  noted  that  any  call  to  MM_ACTIVATE  foe  a 
segment  already  possessing  an  entry  in  the  G_AST  will  not 
effect  any  changes  to  that  entry.  This  is  to  insure  that  a 
single  G_AST  entry  exists  for  every  segaent  as  specified  by 
Moore  and  Gary  [5]. 

B.  EBBSBEI  IMTEBBOPTS 

Various  refineaents  were  aade  in  the  handling  of  both 
physical  (hardware)  and  virtual  (software)  preempt  inter¬ 
rupts.  A  hardware  preeapt  is  a  non-vectored  interrupt  that 
invoices  the  virtual  processor  scheduling  aechanisa  (viz., 
ITC  GETWOBK) .  A  virtual  preeapt  is  a  software  vectored  in¬ 
terrupt  that  invoices  the  user  process  scheduling  aechanisa 
(viz.,  TC_GETWQRK) .  This  iaple mentation  provides  the  notion 
of  a  virtual  interrupt  that  closely  airrors  the  behavior  of 
a  hardware  interrupt.  In  particular,  there  are  siailar  con¬ 
structs  for  initialization  of  a  handler,  invokatjon  of  a 
handler,  masking  of  interrupts,  and  return  froa  a  handler. 
As  with  aost  hardware  interrupts,  a  virtual  interrupt  can 
occur  only  at  the  completion  of  execution  for  an  "instruc¬ 
tion,  N  where  each  kernel  entry  and  exit  for  a  process  delia- 
it  a  single  "virtual  instruction." 
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The  physical  preeapt  handler  resides  in  the  virtual  pro¬ 
cessor  aanager  (viz..  Inner  Traffic  Controller).  The  func¬ 
tions  it  perfora  are:  1)  save  the  execution  point,  2)  in¬ 
voke  ITC  GETWORK,  3)  check  for  virtual  preeapt  interrupts, 
4)  restore  the  execution  point,  and  5)  return  control  via 
the  1B2T  instruction.  Beitz  [12]  included  the  hardware 
preeapt  handler  in  ITC  GETWORK  by  establishing  two  entry 
points  and  two  exit  points,  one  for  a  regular  call  to 
GETWORK  and  another  for  the  preeapt  interrupt.  He  had  a  se¬ 
parate  procedure,  TEST_PBEEHPT,  that  was  used  to  check  for 
the  occurrence  of  virtual  preeapt  interrupts.  This  structure 
works  nicely,  but  it  requires  soae  aeans  of  deter aining  how 
GETWORK  was  invoked  so  that  the  proper  exiting  aechanisa  is 
used.  This  was  resolved  by  incorporating  a  preeapt  inter¬ 
rupt  flag  in  the  status  register  block  of  every  process* 
Kernel  doaain  stack  segaent.  i  design  decision  was  aade  to 
restructure  the  hardware  preeapt  handler  into  a  single  and 
separate  procedure,  PHTS_PREEHPT_HAHDLER.  This  allowed  ITC 
GETWORK  to  have  a  single  entry  and  exit  point,  and  it  did 
away  with  the  necessity  of  aaintaining  a  preeapt  interrupt 
flag  in  the  process  stacks.  PHYS_EBEEH?T_HAHDLER  was  con¬ 
structed  froa  the  preeapt  handling  code  in  GETWORK  and 
procedure  TESI.PBEEBPT.  TEST_PREEHPT  was  delated  froa  the 
ITC  as  its  functions  were  perforaed  by  PHTS_?REEHPT-H ANDLEB . 
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k  farther  refinement  was  aade  to  the  hardware  preeapt 
handler  dealing  with  the  aethod  by  which  the  virtual  preeapt 
handler  was  invoiced.  Reitz  [12]  invoiced  the  virtual  preeapt 
handler  froa  TEST_PBEEHPT  by  aeans  of  the  "call"  instruc¬ 
tion.  Since  the  virtual  preeapt  handler  logically  exists  at 
a  higher  level  of  abstraction  than  the  ITC,  this  invocation 
violated  our  notion  of  only  allowing  "calls"  to  lower  or 
equal  abstraction  levels.  However,  this  deviation  was  ne¬ 
cessitated  by  the  absence  of  a  virtual  interrupt  structure. 
This  problea  was  alleviated  by  creating  a  virtual  interrupt 
vector  in  the  ITC  that  is  used  in  the  sane  way  as  the  hard¬ 
ware  interrupt  vector.  The  virtual  preeapt  was  given  a  vir¬ 
tual  interrupt  nuaber  (zero).  The  virtual  interrupt  handler 
is  then  invoked  by  aeans  of  a  "juap"  through  the  virtual  in¬ 
terrupt  vector  for  virtual  interrupt  nuaber  0.  This  invoca¬ 
tion  occurs  in  the  sane  Banner  that  the  handlers  for  hard¬ 
ware  interrupts  are  invoiced.  The  virtual  interrupt  vector 
is  created  by  procedure  CREATE_XNT_VEC.  CREATE_IRT_TEC  ac¬ 
cepts  as  arguments  a  virtual  interrupt  nuaber  and  the  ad¬ 
dress  of  the  interrupt  handler.  The  creation  of  the  virtual 
preeapt  entry  in  the  virtual  interrupt  vector  is  accom- 
plished  at  the  tiae  of  the  Traffic  Controller  initialization 
by  TC_IHIT. 
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2.  liciaai  EUiaci  Handler 

The  virtual  preeapt  handler  (VIRT_PBEEHPT_HA MOLES)  re¬ 
sides  in  the  user  process  aanager  (viz.,  the  Traffic  Cont¬ 
roller)  .  The  functions  performed  by  VIST. PREEMPT. HANDLER 
are:  1)  deteraine  the  VP  ID  of  the  virtual  processor  being 
preeapted,  2)  invoice  the  process  scheduling  aechanisa  (viz., 
TC.GETMORK) ,  and  3)  return  control  via  a  virtual  interrupt 
return.  The  correct  VP  ID  is  obtained  by  calling  R(JNNING<_VP 
in  the  ITC.  The  Active  Process  Table  is  then  locked,  and 
the  state  of  the  process  running  on  that  VP  is  changed  to 
"ready."  At  this  tiae,  process  scheduling  is  effected  by 
calling  TC_G3TWORK.  Once  process  s  heduling  is  coapleted, 
the  APT  is  unlocked  and  control  is  returned  via  a  virtual 
interrupt  return.  This  virtual  interrupt  return  is  aerely  a 
juap  to  the  PREEMPT_RET  label  in  the  hardware  preeapt  han¬ 
dler  (This  juap  emulates  the  action  of  the  IRET  instruction 
for  a  hardware  interrupt  return) .  This  label  is  the  point 
at  which  the  virtual  preeapt  interrupts  are  unaasked. 

All  Kernel  processes  are  initialized  to  appear  as  though 
they  are  returning  froa  a  hardware  preempt  interrupt.  All 
user  processes  initially  appear  to  be  returning  froa  a  vir¬ 
tual  preeapt  interrupt.  Therefore,  the  initial  conditions 
of  a  process*  Kernel  domain  stack  is  largely  influenced  by 
the  stack  manipulation  of  the  preeapt  handlers.  Figure  44 
illustrates  the  initial  Kernel  domain  stack  structure  for 
all  systea  processes. 
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Figure  44:  Initial  Process  Stack 
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The  initial  Kernel  Flag  Control  fiord  (FCff)  value  is 
"5000",  indicating  non-segaented  code,  system  aode  of  opera- 
tion,  non-vectored  interrupts  masked,  and  vectored  inter¬ 
rupts  enabled.  The  Current  Stack  Pointer  value  is  set  to 
the  first  entry  in  the  stack  (viz.,  SP) .  The  IB ET  Fraae  is 
the  portion  of  the  Kernel  stack  affected  by  the  IBET  in¬ 
struction.  The  first  element.  Interrupt  ID  (set  to  "PFFF") 
is  aerely  popped  off  of  the  stack  and  discarded.  The  next 
eleaent.  Initial  FCR ,  is  popped  and  placed  in  the  system 
Flag  Control  fiord.  Initial  FCfi  is  set  to  "5GG0"  for  Kernel 
processes  and  "1800"  (indicating  normal  aode  with  all  inter¬ 
rupts  enabled)  for  user  processes.  The  final  element  of  the 
IBET  fraae.  Initial  IC  is  popped  off  of  the  stack  and 
placed  in  the  program  counter  (PC)  register.  This  value  is 
initialized  as  the  entry  address  of  the  process  in  question. 

The  "register"  entries  on  the  stack  represent  the  ini¬ 
tial  register  contents  for  the  process  at  the  beginning  of 
its  execution.  Since  the  Kernel  processes  (viz.,  BE  and 
Idle)  do  not  require  any  specific  initial  register  states, 
their  entries  reflect  the  register  contents  at  the  tiae  of 
stack  creation.  Initial  register  conditions  are  used  zo 
provide  initial  "parameters'*  required  by  the  user  processes. 
This  will  depend  largely  upon  the  parameter  passing  conven¬ 
tions  of  the  iapleaentation  language.  The  aeans  for  regis¬ 
ter  initialization  was  provided  through  CBEATE_PBOCESS;  how¬ 
ever,  the  only  initial  register  condition  used  for  the  user 
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processes  in  this  demonstration  was  register  #13.  Begister 
#13  was  used  to  pass  the  user  ID/Host  number  of  the  process 
created.  This  value  is  utilized  by  the  user  process  in  ac¬ 
tivating  the  segaent  used  for  inter-process  coaaunication 
between  a  Host's  File  Manager  and  I/O  processes.  Another 
logical  parameter  passed  to  the  user  processes  is  the  root 
segaent  nuaber.  This  did  not  require  a  register  for  passing 
in  the  deaonstration  as  it  is  known  to  be  the  first  entry  in 
the  KST  for  all  processes.  The  N_S_P  entry  on  the  stack 
represents  the  initial  value  of  the  noraal  stack  pointer. 
For  user  processes,  this  value  is  obtained  when  the  Supervi¬ 
sor  doaain  stack  for  that  process  is  created.  For  Kernel 
processes,  this  value  is  set  to  "FFFF"  since  they  execute 
solely  in  the  Kernel  doaain  and  have  no  Superivsor  doaain 
stack.  The  Preeapt  Beturn  Point  specifies  the  address  where 
control  will  be  passed  once  the  process'  VP  is  scheduled  and 
the  "return"  froa  ITC  GETVOBK  is  executed.  For  Kernel  pro¬ 
cesses,  this  is  the  point  within  the  hardware  preeapt  han¬ 
dler  where  the  virtual  processor  table  is  unlocked.  For 
user  processes,  this  is  the  point  within  the  virtual  preeapt 
handler  where  the  Active  Process  Table  is  unlocked. 

It  is  important  to  note  that  if  the  APT  was  not  unlocked 
when  a  user  process  began  its  initial  execution,  the  s ystea 
would  become  deadlocked  and  no  further  process  scheduling 
could  occur.  It  should  be  further  noted  that  the  initial 
stack  conditions  for  user  processes  do  not  reflect  a  valid 
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history  of  execution .  The  "normal"  history  of  a  user  pro¬ 
cess  returning  froa  ITC  GETUOBK  after  a  virtual  preempt  in¬ 
terrupt  would  reflect  the  passing  of  control  through 
SBAP_VDB8  and  ?C_GETWOBK  to  the  point  in  the  virtual  preeapt 
handler  where  the  APT  is  unlocked.  Another  "possible"  his¬ 
tory  could  reflect  the  occurrence  of  a  hardware  preeapt  in¬ 
terrupt  at  the  point  in  the  virtual  preeapt  handler  where 
the  APT  is  unlocked.  such  a  history  would  be  depicted  by 
replacing  the  current  top  of  the  stack  with  the  return  point 
into  the  hardware  preeapt  handler  (viz.,  at  the  point  of 
virtual  preempt  interrupt  unmasking)  and  an  additional  hard¬ 
ware  preempt  interrupt  frame  whose  IC  value  in  the  IBE? 
fraae  is  the  point  in  the  virtual  preempt  handler  where  the 
APT  is  unlocked.  The  current  initial  stack  condition  for 
user  processes  was  chosen  for  its  ease  of  understanding  and 
its  clear  depiction  of  the  fact  that  the  structure  of  a  Ker¬ 
nel  domain  stack  is  the  same  for  both  Kernel  and  user  pro¬ 
cesses. 

c.  Ifii.fi  ES2£fiS5S5 

In  the  SASS  design,  there  logically  exists  a  Kernel  do¬ 
main  "Idle"  process  for  every  physical  processor  in  the  sys¬ 
tem  and  a  Supervisor  domain  "Idle"  process  for  every  "TC  vi¬ 
sible"  virtual  processor  in  the  system.  These  processes  are 
necessary  to  insure  that  both  the  VP  scheduler  (viz.,  ITC 
GETWOBK)  and  the  process  scheduler  (TC_GBTH0B K)  will  always 


have  soee  object  )  schedule,  hence  precluding  any  CPU  or  VP 
fro*  ever  having  an  undefined  execution  point.  Since  the 
Kernel  doeain  Idle  process  perforss  no  useful  work,  it  could 
be  included  within  the  ITC  by  seans  of  an  infinite  looping 
aechanisa.  The  Kernel  Idle  process  was  aaintained  separate¬ 
ly,  however,  as  it  is  hoped  that  future  work  on  SASS  will 
provide  this  Idle  process  with  soae  constructive  purpose 
(e.g.,  perforaing  aaintenance  diagnostics). 

The  Supervisor  doaain  Idle  processes  (hereafter  referred 
to  as  TC  Idle  processes)  are  scheduled  (bound)  on  VP's  when 
there  are  no  user  processes  awaiting  scheduling.  Since  a  TC 
Idle  process  perforas  no  user  constructive  work,  we  do  not 
want  any  VP  executing  a  TC  Idle  process  to  be  bound  to  a 
physical  processor.  In  other  words,  a  VP  bound  to  a  TC  Idle 
process  assuaes  the  lowest  systea  priority  (represented  by 
the  "idle  flag").  Therefore,  any  such  vp  will  have  its  idle 
flag  set  and  will  not  be  scheduled  unless  it  receives  a  vir¬ 
tual  preeapt  interrupt.  Such  an  interrupt  will  allow  the  vp 
to  be  rescheduled  by  the  Traffic  Controller.  It  should  be 
obvious,  at  this  point,  that  a  TC  Idle  process  will  never 
actually  begin  execution  on  a  real  processor.  This  know¬ 
ledge  allowed  a  design  decision  to  be  made  to  only  sinulate 
the  existence  of  TC  Idle  processes.  At  the  TC  level,  this 
was  accoaplished  by  a  constant  value,  IDLE_PBOC,  that  was 
used  as  a  process  ID  in  the  APT  running  list,  thus  preclud¬ 
ing  the  necessity  of  any  "Idle"  entries  in  the  APT.  An  the 
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XTC  level,  any  VP  narked  "idle"  (viz.,  the  idle  flag  set) 
was  given  the  DBB  nusber  (viz.,  address  space)  of  the  Kernel 
Idle  process  solely  to  provide  the  use  of  a  Kernel  doeain 
stack  for  rescheduling  of  the  VP. 

D.  ACfiixiQBAL  sssasi  asmsasixs 

In  addition  to  those  already  discussed,  several  other 
refineaents  to  existing  Kernel  nodules  sere  effected  in  this 
iapleaentation.  One  of  these  refineaents  deals  with  the  way 
virtual  processors  are  identified  by  tne  Traffic  Controller. 
In  the  current  iapleaentation,  all  TC  visible  virtual  pro¬ 
cessors  are  given  an  External  VP  ID  which  corresponds  to  its 
entry  nuaber  in  an  External  VP  List.  This  required  a  aodi- 
fication  to  the  ITC  procedure  RUHHIMGJfP.  The  benefits  der¬ 
ived  froa  this  refineaent  included  the  ability  to  directly 
access  the  External  VP  ID  in  the  Virtual  Processor  Table 
vice  the  reguireaent  of  a  run  tiae  division  to  coapute  its 
value  and  the  ability  to  use  the  External  vp  ID  as  an  index 
into  the  TC  running  list. 

Refineaents  were  also  aade  to  the  existing  Meaory  Manag¬ 
er,  File  Manager  and  10  process  stubs  used  for  deaonstraticn 
purposes.  These  refineaents  were  largely  associated  with 
the  eventcount  and  sequencer  aechanisas  utilized  in  this  ia- 
pleaentation.  The  current  status  of  these  processes  is  pro¬ 
vided  in  this  report. 


The  resaining  refinements  deal  largely  with  the  MHO  la- 
age.  In  Moore  and  Gary's  £5]  design,  the  MMU  Image  was  man¬ 
aged  by  the  Memory  Manager  process.  This  was  largely  be¬ 
cause  the  MHO  Image  is  a  processor  local  database  and  would 
seem  well  suited  for  management  by  the  non-distributed  Ker¬ 
nel.  In  fact,  the  MMO  Image  is  utilized  mainly  by  the  ITC 
for  the  multiplexing  of  process  address  spaces.  Therefore, 
in  the  current  design,  the  MMO  Images  are  maintained  by  the 
Inner  Traffic  Controller.  However,  the  MMO  header  proposed 
by  Moore  and  Gary  (viz.,  the  8LOCKS_OSED  and 
MAXIMUH_AVAILABLE_BLOCKS  fields)  was  retained  in  the  Memory 
Manager  as  it  is  used  strictly  in  the  management  of  a  pro¬ 
cess'  virtual  core  and  is  not  associated  with  the  hardware 
MMO. 

In  Hells'  design  [20],  the  Traffic  Controller  used  the 
linear  ordering  of  the  DBS  entries  in  the  MHO  Image  as  the 
DBB  handle  (viz.,  1,2,3...).  This  required  a  run  time  divi¬ 
sion  operation  to  compute  the  DBB  numoer,  and  a  run  time 
multiplication  operation,  by  MM_GET_DBB_?AL0E,  to  recompute 
the  DBB  address  for  use  by  the  ITC.  In  the  current  design, 
the  offset  of  the  DBB  entry  in  the  HHU  Image  (obtained  at 
the  time  of  MHO  allocation)  is  used  as  the  DBS  handle  in  the 
Traffic  Controller.  Furthermore,  SHAP_VDBB  was  refined  to 
accept  a  DBR  handle  rather  than  a  DBB  address  to  preclude 
the  necessity  of  the  Traffic  Controller  having  to  deal  with 
MMO  addresses.  DBB  addresses  are  computed  only  within  the 
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ITC  (viz.,  by  procedure  GET_DBfi_ADDB)  by  adding  the  value  of 
the  DBS  handle  to  the  base  address  of  the  MMU  Isage.  Since 
DBS  addresses  are  now  used  solely  within  the  ITC,  procedure 
HM_GET_DBB_ VALUE  was  no  longer  needed  and  was  deleted  fros 
the  Memory  Manager. 

E.  SUMMAB Y 

The  primary  issues  addressed  in  this  thesis  effort  have 
been  presented  in  this  chapter.  Aside  fros  the  process  Ban- 
agenent  functions,  this  description  included  a  nechanisa  for 
liaited  Kernel  database  initialization,  a  revised  preeapt 
interrupt  handling  nechanisa,  the  creation  of  a  virtual  in¬ 
terrupt  structure,  a  definition  of  "idle"  processes  and 
their  structure,  and  a  discussion  of  the  ainor  refinements 
effected  in  existing  SASS  modules.  A  detailed  description 
of  the  implementation  of  process  management  functions  for 
the  SASS  is  presented  in  the  next  chapter. 


Chapter  XXII 

PROCESS  MAMAGBHERT  IMPLEMENTATION 


The  implementation  of  process  aanageaent  functions  and  a 
gate  keeper  stub  (system  trap)  is  presented  in  this  chapter. 
The  iapleaentation  is  discussed  in  terns  of  the  Event  Manag¬ 
er,  Traffic  Controller,  Distributed  Menory  Manager,  User 
Gate,  and  Kernel  Gate  Keeper  nodules.  A  block  diagraa  dep¬ 
icting  the  structure  and  interrelationships  of  these  aodules 
is  presented  in  Pigure  45.  Support  in  developing  the  Z8000 
aachine  code  for  this  iapleaentation  was  provided  by  a  Zilog 
MCZ  Developaental  Systea  operating  under  the  RIO  operating 
systea.  The  Developaental  Systea  provided  disk  file  aanage- 
aent  for  a  dual  drive,  hard  sectored  floppy  disk,  a  line 
oriented  t9xt  editor,  a  PLZ/ASM  asseabler,  a  linker  and  a 
loader  that  created  an  executable  image  of  each  Z8000  load 
nodule.  An  upload/download  capability  with  the  Aa96/4116 
MonoBoard  coaputer  was  also  provided.  This  capability, 
along  with  the  general  interfacing  of  the  Aa96/4116  into  the 
SASS  systea,  was  accomplished  in  a  concurrent  thesis  endea¬ 
vor  by  Gary  Baker.  Baker's  work  relating  to  hardware  ini¬ 
tialization  in  SASS,  will  be  published  upon  coapletion  of 
his  thesis  work  in  June  1981. 
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Figure  45:  Iapleientation  Module  Structure 


a.  SI5SI  1A8AS2&  bodolb 

The  eventcount  and  sequencer  priaitives  [11],  which  are 
systea-wide  objects,  collectively  coaprise  the  event  data  of 
SASS.  is  aentioned  earlier,  this  event  data  is  tied  direct¬ 
ly  to  systea  segments  and  is  stored  in  the  Global  Active 
Segment  Table.  There  are  two  eventcouats  and  one  sequencer 
for  every  segment  in  the  systea.  These  objects  are  identi¬ 
fied  to  the  Kernel  in  user  calls  by  specification  of  a  seg¬ 
ment  nuaber.  Once  this  segaent  number  is  identified  by  the 
Kernel,  the  segment's  handle  can  be  obtained  froa  the  pro¬ 
cess'  Known  Segment  Table.  The  segaent  handle  identifies 
the  particular  entry  in  the  G_4ST  containing  the  event  data 
desired. 

The  Event  Manager  module  manages  the  event  data  within 
the  systea  and  provides  the  aechanisa  for  interprocess  coa- 
munication  between  user  processes.  The  Event  Manager  con¬ 
sists  of  six  procedures.  Four  of  these  (Advance,  Await, 
Read,  and  Ticket)  represent  the  four  user  extended  instruc¬ 
tions  provided  by  the  Event  Manager.  The  reaaining  two 
procedures  provide  internal  computational  support  to  include 
necessary  security  checking.  The  Event  Manager  is  invoked 
solely  by  user  processes,  via  the  Gate  Keeper,  through  uti¬ 
lization  of  the  extended  instruction  set  provided.  For  ev¬ 
ery  Event  Manager  extended  instruction  invoked  by  a  user 
process,  the  non-discretionary  security  is  verified  by  coa- 
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paring  the  security  access  classification  of  the  process  in¬ 
voking  the  instruction  with  the  classification  of  the  object 
(segaent)  being  accessed,  access  to  the  user  process'  Known 
Segaent  Table  is  required  by  the  aodule  in  order  to  ascer¬ 
tain  the  segaent  handle  and  security  class  for  a  given  seg¬ 
aent  nuaber.  The  PLZ/ASM  assembly  language  listing  for  the 
Event  Manager  aodule  is  provided  in  Appendix  A.  A  more  de¬ 
tailed  discussion  of  the  procedures  comprising  the  Event 
Manager  follows. 

1  •  §SB£2££  £E gggflii-r-.es 

The  procedures  GET_HAMDL£  and  COHVEBT„AiiD_VEBIFI  provide 
internal  support  for  the  Event  Manager  and  are  not  visible 
to  the  user  processes.  Procedure  CCM7EBT_AND_7EBIFY  is  in¬ 
voked  by  the  four  procedures  representing  the  instruction 
set  of  the  Event  Manager.  The  input  parameters  to 
CONVERT_AND_YERIFY  are  a  segment  nuaber  and  a  requested  mode 
of  access  (viz.  ,  read  or  write)  .  COHVERT_>AND_¥ERIFY  returns 
a  pointer  to  the  segaent *s  handle  and  a  success  code. 
Procedure  GET_HA  HOLE  is  invoked  solely  by 
COHVERT_AHD_TERIFT.  The  input  parameter  to  GET_HANDLE  is 
the  segment  number  received  as  input  by  CQNVEBT.AND. VERIFY. 
GET_H ANDL2  returns  a  pointer  to  the  segment' s  handle,  a 
pointer  to  the  segment' s  security  classification,  and  a  suc¬ 
cess  code.  A  discussion  of  the  functions  provided  by  these 
support  procedures  follows. 


Procedure  GET_HANDLE  translates  the  segaent  number#  re* 
ceited  as  input#  into  a  KST  index  nuaber  and  verifies  that 
the  resulting  index  nuaber  is  valid.  Next  the  base  address 
of  the  process'  KS?  is  obtained  froa  procedure 
ITC_GET_SE3_PTR .  The  KST  index  nuaber  is  then  converted 
into  a  KST  offset  value  and  added  to  the  base  address  to  ob¬ 
tain  the  appropriate  KST  entry  pointer  for  the  segaent  in 
question.  A  verification  is  then  aade  to  insure  that  the 
referenced  segaent  is  "known"  to  the  process.  If  the  seg¬ 
aent  is  not  known#  an  error  aessage  is  returned  to 
CONVERT _and_VER IP  Y .  Otherwise#  a  pointer  to  the  segaent* s 
handle  is  obtained  to  identify  the  segaent  to  the  aeaory 
manager.  A  pointer  to  the  segment's  security  class  entry  in 
the  KST  is  also  returned  for  use  in  appropriate  security 
checks. 

Procedure  CONVERT_AND_VEBIFT  provides  the  necessary 
non-discretionary  security  verification  for  the  extended  in¬ 
struction  set  of  the  Event  Hanager.  Procedure  GET_HANDLE 
is  invoked  for  segaent  nuaber  verification  and  to  obtain 
pointers  to  the  segaent's  handle  and  security  class.  If 
GET_HANDLE  returns  with  a  successful  verification,  the  pro¬ 
cess'  security  class  is  coapared  to  the  segaent's  security 
class  to  verify  the  aode  of  access  requested.  A  request  for 
"write"  access  causes  invocation  of  the  CLASS.EQ  function  in 
the  Non-Discretionar y  Security  Nodule  to  insure  that  the  se¬ 
curity  classification  of  the  process  is  equal  to  the  classi- 


fication  of  the  eventcount  or  sequencer,  which  is  the  saae 
as  that  of  the  segaent.  Otherwise,  the  CLASSJ5E  function  is 
called  to  verify  that  the  process  has  read  access.  If  the 
appropriate  security  check  is  unsuccessful,  an  error  code  is 
returned  by  COHVERT_AND_VERIFY .  Otherwise,  the  segaent  han¬ 
dle  is  returned  along  with  a  success  code  of  "succeeded"  in¬ 
dicating  that  the  user  process  possesses  the  necessary  se¬ 
curity  clearance  to  coaplete  execution  of  the  extended 
instruction. 

2.  £S4d 

Procedure  READ  ascertains  the  current  value  of  a  user 
specified  eventcount  and  returns  its  value  to  the  caller. 
The  input  paraaeters  to  READ  are  a  segaent  nuaber  and  an 
instance  (viz.,  an  event  nuaber).  COHV EB T_A N D_T E BIFT  is  in¬ 
voked  with  a  "read"  access  request  to  obtain  the  segaent' s 
handle  and  necessary  verification.  "Read"  access  is  suffi¬ 
cient  for  this  operation  as  it  only  requires  observation  of 
the  current  eventcount  value  and  perforas  no  data  aodifica- 
tion.  If  verification  is  successful,  procedure 
a H_READ_E7 ENTCO OUT  is  called  to  obtain  the  eventcount  value. 

3 .  lisHfii 

Procedure  TICKET  returns  the  current  sequencer  value  for 
the  segaent  specified  by  the  user.  C0H7£fiT_AKD_VERIFT  is 
called  with  a  request  for  write  access  to  obtain  verifica- 
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tion  and  the  segaent  handle.  write  access  is  required  be¬ 
cause  once  the  sequencer  value  is  read  it  sust  be  increment¬ 
ed  in  anticipation  of  the  next  ticket  request.  Once  verifi¬ 
cation  is  cosplete,  MH_TICKET  is  invoked  to  obtain  the  se¬ 
quencer  value  that  is  returned  to  the  user  process.  It  is 
noted  that  every  call  to  TICKET  for  a  particular  segeent 
nuaber  will  return  a  unique  and  tine  ordered  sequencer  va¬ 
lue.  This  is  because  the  sequencer  value  aay  only  be  read 
within  SH_TICKET  while  the  G„1ST  is  locked,  thereby  prevent¬ 
ing  siaultaneous  read  operations.  Futhernore,  once  the  se¬ 
quencer  value  is  read  it  is  increaented  before  the  G_AST  is 
unlocked. 

Procedure  AWAIT  allows  a  user  process  to  block  itself 
until  soae  specified  event  has  occurred.  The  paraaeters  to 
AWAIT  include  a  segaent  nuaber  and  instance,  which  identify 
a  particular  event,  and  a  user  specified  value  which  identi¬ 
fies  a  particular  occurrence  of  the  event.  Verification  of 
read  access  and  a  pointer  to  the  segaent* s  handle  is  ob¬ 
tained  fcoa  procedure  C0HVEBT_1HD_VE8IFI .  Procedure 
TC.AWAIT  is  invoked  to  effect  the  actual  waiting  for  the 
event  occurrence.  TC.AWAIT  will  not  return  to  AWAIT  until 
the  requested  event  has  occurred.  It  is  noted  that  AWAIT 
aakes  no  assuaptions  about  the  event  value  specified  by  the 
user.  Therefore,  the  Kernel  cannot  guarantee  that  the  event 
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specified  by  the  user  will  ever  occur;  this  is  the  responsi¬ 
bility  of  other  cooperating  user  processes. 

5.  i&aass 

Procedure  ADVANCE  allows  a  user  process  to  broadcast  the 
occurrence  of  soae  event.  This  is  accoaplished  by  incre¬ 
menting  the  value  of  the  eventcount  associated  with  the 
event  that  has  occurred.  The  parameters  to  ADVANCE  include 
a  segment  number  and  instance  which  identify  a  particular 
event.  The  calling  process  must  have  write  access  to  the 
identified  segment  as  modification  of  the  eventcount  is  re¬ 
quired.  Verification  of  write  access  and  a  pointer  to  the 
segment's  handle  is  obtained  through  procedure 
CONVEHT_AND_VERIPT .  Procedure  TC^ADVAMCE  is  invoked  to  per¬ 
form  the  actual  broadcasting  of  event  occurrence. 

b.  XUinS  S3B1MQLLM  &&MLB 

The  primary  functions  of  the  Traffic  Controller  module 
are  user  process  scheduling  and  support  of  the  inter-process 
communication  mechanism.  The  Traffic  Controller  is  invoked 
by  the  occurrence  of  a  virtual  preempt  interrupt  and  by  the 
Event  Manager  and  the  Segment  Manager  through  the  extended 
instruction  set;  TC_Advance,  TC_Await,  Process_Class#  and 
Get_DBR_MOMBER.  The  Traffic  Controller  module  is  comprised 
of  nine  procedures.  Four  of  these  procedures  represent  the 
extended  instruction  set  of  the  Traffic  Controller.  A  de- 


tailed  discussion  of  six  of  the  procedures  contained  in  the 
Traffic  Controller  nodule  is  presented  below.  The  regaining 
three  procedures  (viz*,  TC.INIT,  CBEAIE_PROCESS ,  and 
CBEATE.KST)  were  described  in  chapter  three.  The  PIZZAS* 
assembly  language  source  code  listings  for  the  Traffic  Cont¬ 
roller  aodule  is  provided  in  Appendix  B. 

Procedure  TC_GETJfOBK  provides  the  sechanisa  for  user 
process  scheduling.  The  input  paraaeters  to  TC_GETHOBK  are 
the  TP  ID  of  the  virtual  processor  to  which  a  process  will 
be  scheduled  and  the  logical  CPU  nuaber  to  which  the  virtual 
processor  belongs.  The  deteraination  of  which  process  to 
schedule  is  aade  by  a  looping  aechanisn  that  finds  the  first 
"ready"  process  on  the  ready  list  associated  with  the  cur¬ 
rent  logical  CPU  nuaber.  Processes  appear  in  the  ready  list 
by  order  of  priority.  This  looping  aechanisa  is  required  as 
both  "running"  and  "ready"  processes  are  naintained  on  the 
ready  list.  This  ready  list  structure  was  chosen  to  sinpli- 
fy  the  algorithm  provided  in  procedure  TC_Advance.  If  a 
ready  process  is  found,  its  state  is  changed  to  "running" 
and  its  process  ID  (viz.,  the  APT  entry  nuaber)  is  inserted 
in  the  running  list  entry  associated  with  the  current  virtu¬ 
al  processor.  Procedure  s*AP_7DBB  is  then  invoked  in  the 
Inner  Traffic  Controller  to  effect  the  actual  process 
switch.  If  a  ready  process  was  not  found  (viz.,  the  ready 


list  was  empty  or  comprised  solely  of  “running  processes'*)  , 
then  the  running  list  entry  associated  with  the  current  vir¬ 
tual  processor  is  aarked  with  the  constant  Nldle_ProcN  and 
procedure  IDLE  is  invoked  in  the  Inner  Traffic  Controller. 

2. 

The  priaary  function  of  TC_AHAIT  is  the  deteraination  of 
whether  soae  user  specified  event  has  occurred.  If  the 
event  has  occured,  control  is  returned  to  the  caller.  Oth¬ 
erwise,  the  process  is  blocked  and  another  process  is  sche¬ 
duled.  The  input  paraaeters  to  TC_AHAIT  are  a  pointer  to  a 
segaent  handle,  an  instance  (event  nuaber) ,  and  a  user  spe¬ 
cified  eventcount  value.  TC_AHAIT  initially  locks  the  Ac¬ 
tive  Process  Table  and  obtains  the  current  value  of  the  ev¬ 
entcount  in  question  by  calling  procedure 
MH_READ_EVENTCOONT.  The  deteraination  of  event  occurrence 
is  aade  by  coaparing  the  user  specified  eventcount  value 
with  the  current  eventcount.  If  the  user  value  is  less  than 
or  equal  to  the  current  eventccunt,  the  awaited  event  has 
occurred  and  control  is  returned  to  the  caller.  Otherwise, 
the  awaited  event  has  not  yet  occurred  and  the  process  aust 
be  blocked. 

If  the  process  is  to  be  blocked,  procedure  BUHNING_7P  is 
invoked  to  ascertain  the  7P  ID  of  the  virtual  processor 
bound  to  the  process.  The  process'  ID  (viz.,  APT  entry  nua¬ 
ber)  is  then  read  froa  the  running  list.  The  input  paraae- 
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ters  to  TC_A8AIT  (viz..  Handle,  Instance,  and  Value)  are 
then  stored  in  the  Event  Data  portion  of  the  process'  APT 
entry.  The  process  is  resoved  fro*  its  associated  ready 
list  by  redirecting  the  appropriate  linking  threads  (poin¬ 
ters)  .  Once  resoved  fros  the  ready  list,  the  process  is 
threaded  into  the  blocked  list  and  its  state  changed  to 
"blocked"  by  invocation  of  the  library  function  LIST_IHSEBT. 
Procedure  TC_GETWOBK  is  then  called  to  schedule  another  pro¬ 
cess  for  the  current  virtual  processor. 

3 •  xC-Aiiaass 

The  prisary  purpose  of  TC_ADVAHCE  is  the  broadcasting 
of  soae  event  occurrence.  This  entails  incrementing  the  ev- 
entcount  associated  with  the  event,  awakening  all  processes 
that  are  waiting  for  the  event,  and  insuring  proper  schedul¬ 
ing  order  by  generating  any  necessary  virtual  preempt  inter¬ 
rupts.  The  high  level  design  algorithm  for  TC.AOVAMCE  is 
provided  in  Figure  46.  The  input  parameters  to  TC_ADVANCE 
are  a  pointer  to  a  segment's  handle  and  an  instance  (event 
number).  Initially,  TC_ADVAHCE  locks  the  APT  to  prevent  the 
possibility  of  a  race  condition.  The  eventcount  identified 
by  the  input  parameters  is  then  incremented  by  calling 
HN_ADVANCE.  HH_ADV  AHCE  returns  the  new  value  of  the  event- 
count.  Once  the  eventcount  has  been  advanced,  TC_ADVANCE 
awa&ens  all  processes  awaiting  this  event  occurrence.  This 
is  accomplished  by  checking  all  processes  that  are  currently 
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in  the  blacked  list.  The  process'  HANDLE  and  INSTANCE  en¬ 
tries  are  coapared  with  the  handle  and  instance  identifying 
the  current  event.  If  they  are  the  sane,  then  the  process 
is  awaiting  soae  occurrence  of  the  current  event.  In  such  a 
case,  the  process'  VALUE  entry  in  the  APT  is  coapared  with 
the  current  value  of  the  eventcount.  If  the  process'  VALUE 
is  less  than  or  equal  to  the  current  eventcount  value,  the 
awaited  avent  has  occurred  and  the  process  is  reaoved  froa 
the  blocked  list  and  threaded  into  the  appropriate  ready 
list  by  the  library  function  LIST_INSEfiT. 

Once  the  blocked  list  has  been  checked,  it  is  necessary 
to  reevaluate  each  ready  list  to  insure  that  the  highest 
priority  processes  are  running.  It  is  relatively  siaple  to 
deteraine  if  a  virtual  preeapt  interrupt  is  necessary,  how¬ 
ever,  it  is  considerably  aore  difficult  to  deteraine  which 
virtual  processor  should  receive  the  virtual  preeapt.  To 
assist  in  this  evaluation,  a  "count"  variable  (number  of 
preeapts  needed)  is  zeroed  and  a  preeapt  vector  is  created 
on  the  Kernel  stack  with  an  entry  for  every  virtual  proces¬ 
sor  associated  with  the  logical  CPU  being  evaluated.  Ini¬ 
tially,  every  entry  in  the  preempt  vector  is  marked  "true" 
indicating  that  its  associated  virtual  processor  is  a  candi¬ 
date  for  preeaption.  Once  the  preeapt  vector^  is  initial¬ 
ized,  the  first  "n"  processes  on  the  ready  list  (where  n 
equals  the  nuaber  of  VP's  associated  with  the  current  logi¬ 
cal  CPU)  are  checked  for  a  determination  of  their  state.  If 
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TC_ADV ANCE  Procedure  (HANDLE,  INSTANCE) 
>gin 

t  Set  new  eventcount  i 

COONT  :»  NM_ADVANCE  (HANDLE,  INSTANCE) 

Call  HAIT_LOCK  (APT) 

!  Hake  up  processes  ! 

PROCESS  :*  BLOCXED_LIST_HEAD 

Do  while  not  end  of  BLOCKED.LISI 
If  (PROCESS. HANDLE  *  HANDLE)  and 

(PROCESS. INSTANCE  *  INSTANCE)  and 
(PROCESS. COONT  <*  COONT) 
then 

Call  LIST_INSERT (READY  LIST) 
end  if 

PROCESS  :*  PROCESS. NEXT_PROCESS 
end  do 

!  Check  all  ready  lists  for  preempts  1 
logical_cpo_.no  :*  1 

Do  while  LOGICAL_CPO_NO  <=  #Nfi_CPO 
!  Initialize  preeapt  rector  1 
?P_ID  :*  PIRSTjrP  (LOGIC AL_CPO_NO) 

DO  for  LOOP  :=  1  to  NB_7P  (LOGICAL_CPU_NO 
RONNING_LIST[?P_ID]. PREEMPT  :*  #TRCE 

VP_ID  ;»  VP_ID  ♦  1 
end  do 

!  Pind  preeapt  candidates  ! 

CANDIDATES  :  =  0 

PROCESS  :«  READY_LIST_HEAD (LOGICAL_CPO_NO) 


Pigure  46:  TC_ADVANCE  Algoritha 


7P_ID  :=  PIBST_7P(LOGICAL_CPO_NO) 

Do  (for  CYCLE  -  1  to  Nfi_VP  (LOGICAL_CPU_NO)  and 
not  end  of  BEADY.LIST (LOGICAL  CPU  HO) 

If  PROCESS  *  #BUNNING 
then 

R0NNING_LIST[7P_ID]. PREEMPT  :»  #PALSE 
else 

CANDIDATES  :=  CAHDI DATES  ♦  1 
end  if 

7P_ID  :=  7P_ID  ♦  1 
PROCESS  :=  PROCESS. NEXT_PBOCESS 
end  do 

!  Preempt  appropriate  candidates  ! 

VP_ID  :=  PIRST_¥P(LOGICAL_CPO_NO) 

Do  for  CHECK  :=  1  to  NB_7P  (LOGICAL_CPO_HO) 

If  (RUNNING  LISTC  VP  ID]. PREEMPT  *  #TBUE)  and 
(CANDIDATES  >  0) 
then 

Call  SET_PRE£MPT  (7P_ID) 

CANDIDATES  :=  CANDIDATES  -  1 
end  if 

7P_ID  :*  7p__ID  ♦  1 
end  do 

LOGIC AL_CPO_NO  :=  LOGICAL_CPU_NO  ♦  1 
end  do 

Call  ONLOCK  (APT) 

Return 

End  TC  AD7ANCB 


Pigure  46:  IC_AD7ANCE  Algorithm  (Continued) 


a  process  is  found  to  be  "running"  then  it  should  not  be 
preempted  as  processes  appear  in  the  ready  list  in  order  of 
priority.  Hhen  a  running  process  is  found,  its  associated 
entry  in  the  preeapt  rector  is  narked  "false."  If  a  process 
is  encountered  in  the  "ready"  state  then  it  should  be  run¬ 
ning  and  the  "count"  variable  is  increaented.  When  the 
first  "n"  processes  hare  been  checked  or  when  we  reach  the 
end  of  the  current  ready  list  (whicherer  cones  first)  ,  the  1 

entries  in  the  preeapt  vector  are  "popped”  froa  the  stack. 

If  an  entry  froa  the  preeapt  rector  is  found  to  be  "true", 
this  indicates  that  its  associated  virtual  processor  is  a 
candidate  for  preenption  since  it  is  either  bound  to  a  lower 
priority  process,  or  it  is  "idle."  In  such  a  case,  the 
"count"  variable  is  evaluated  to  deteraine  if  the  virtual 
processor  associated  with  the  vector  entry  should  be 
preeapted.  If  the  count  exceeds  zero,  a  virtual  preempt  in¬ 
terrupt  is  sent  to  the  VP  and  the  count  is  decremented. 

Otherwise,  no  preeapt  is  sent  as  there  is  no  higher  priority 
process  awaiting  scheduling. 

This  preeaption  algorithm  is  coapleted  for  every  ready 
list  in  the  Active  Process  Table.  Once  all  ready  lists  have 
been  evaluated,  the  APT  is  unlocked  and  control  is  returned 
to  the  caller.  It  is  noted  that  it  is  not  necessary  to  in¬ 
voke  TC_GEIWORK  before  exiting  ADVANCE.  If  the  current  VP 
reguires  rescheduling,  it  will  have  received  a  virtual 
preeapt  interrupt  froa  the  preeaption  algorithm.  If  this 
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has  occurred,  the  VP  will  be  rescheduled  when  its  running 
process  attempts  to  leave  the  Kernel  doaain  and  the  virtual 
preeept  interrupts  are  unmasked. 

« •  virtual  Present  Handler 

viHTrjAL_PBEEMPT_  HANDLES  is  the  interrupt  handler  for 
virtual  preempt  interrupts.  The  entry  address  of 
VIRTOAL_PBEEHPT _HANDLEH  is  naintained  in  the  virtual  inter* 
rupt  vector  located  in  the  Inner  Traffic  Controller.  Dnce 
invoiced,  the  handler  loclcs  the  Active  Process  Table  and  det¬ 
ermines  vhich  virtual  processor  is  being  preeapted  by  call¬ 
ing  BUNNING_VP.  The  process  running  on  the  preeapted  VP  is 
then  set  to  the  "ready"  state  and  TC_GETHOBK  is  invoked  to 
reschedule  the  virtual  processor.  Hhen  TC_GETNOBK  returns 
to  VIHT0AL_P8EEHPT_HANDLEB ,  the  APT  is  unlocked  and  a  virtu¬ 
al  interrupt  return  is  executed.  This  return  is  siaply  a 
jump  to  the  point  in  the  hardware  preeapt  handler  where  the 
virtual  interrupts  are  unaasked.  This  effects  a  virtual  in¬ 
terrupt  return  instruction. 

s.  easaiaina  BE&saflacss 

The  reaaining  two  procedures  in  the  Traffic  controller 
module  represent  the  extended  instructions:  PBOCESS_CLA5S 
and  GET_DBR_NONBEB.  Both  procedures  lock  the  Active  Process 
Table  and  call  BUNNING_VP  to  determine  which  virtual  proces¬ 
sor  is  executing  the  current  process.  The  process  ID  <viz.. 
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APT  entry  Nuaber)  is  then  extracted  froa  the  running  list. 
PROCESS.CLASS  reads  and  returns  the  current  process'  securi¬ 
ty  access  classification  froa  the  APT.  GEI..D BR_N UMBER  reads 
and  returns  the  current  process'  DBR  handle.  It  should  be 
noted  that  in  general  the  DBR  nuaber  provided  by  procedure 
GET_DBE_HtJHBEB  is  only  valid  while  the  APT  is  locked.  Par¬ 
ticularly,  in  the  current  SASS  iapleaentation,  the  Segaent 
Manager  invokes  GET„DBR_NOMBER  and  then  passes  the  obtained 
DBR  nuaber  to  the  Distributed  Memory  Manager  for  utilization 
at  that  level.  In  a  acre  general  situation,  the  process  as¬ 
sociated  with  the  DBR  nuaber  nay  have  been  unloaded  before 
the  DBR  number  was  utilized,  thus  making  it  invalid.  This 
problem  does  not  arise  in  SASS  as  all  processes  remain  load¬ 
ed  for  the  life  of  the  systea. 

c.  BisiBisaxM  asaaix  aisifiii  asms 

The  Distributed  Memory  Manager  module  provides  an  inter¬ 
face  between  the  Segaent  Manager  and  the  Memory  Manager  pro¬ 
cess,  manipulates  event  data  in  the  Global  Active  Segment 
Table  (G_AST) ,  and  dynamically  allocates  available  memory. 
A  detailed  description  of  the  Distributed  Memory  Manager  in¬ 
terface  to  the  Memory  Manager  process  was  presented  by  Hells 
[20].  The  remaining  extended  instruction  set  is  discussed 
in  detail  below.  The  complete  PLZ/ASM  source  listings  for 
the  Distributed  Memory  Manager  module  is  provided  in  Appen¬ 
dix  C. 
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aa_BEAD_E VENTCOUNT  is  invoked  by  the  Event  Manager  and 
the  Traffic  Controller  to  obtain  the  current  value  of  the 
eventcount  associated  with  a  particular  event.  The  input 
parameters  to  this  procedure  are  a  segment  handle  pointer 
and  an  instance  (event  Humber),  which  together  uniquely 
identify  a  particular  event. 

The  G_AST  is  locked  and  the  entry  offset  of  the  segment 
into  the  G.AST  is  obtained  from  the  segment's  handle.  The 
instance  parameter  is  then  validated  to  determine  which  ev¬ 
entcount  is  to  be  read.  If  an  invalid  instance  is  speci¬ 
fied,  control  is  returned  to  the  caller  specifying  an  error 
condition.  Otherwise,  the  current  value  of  the  specified 
eventcount  is  read.  The  G_AST  is  then  unlocked,  and  the 
current  eventcount  value  is  returned  to  the  caller. 

2.  aa_A4iaas§ 

MM_AD7A NCE  is  invoked  by  the  Traffic  Controller  to  re¬ 
flect  the  occurrence  of  some  event.  The  input  parameters  to 
aa_ADVAHCE  are  a  pointer  to  a  segment's  handle  and  a  parti¬ 
cular  instance  (event  number)  . 

The  Global  Active  Segment  Table  is  locked  to  prevent  a 
race  condition,  and  the  offset  of  the  segment's  entry  into 
the  G_AST  is  obtained  from  the  segment  handle.  The  instance 
parameter  is  then  validated  to  determine  which  eventcount  is 
to  be  advanced.  If  an  invalid  instance  is  specified,  an  er- 
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cor  condition  is  returned  to  the  caller  and  no  data  entries 
are  affected.  If  the  instance  value  is  valid,  the  appropri¬ 
ate  eventcount  is  incremented,  and  its  new  value  is  re¬ 
turned. 

3.  aa_iis*ai 

HM_TICKET  is  invoked  by  the  Event  Manager  to  obtain  the 
current  value  of  the  sequencer  associated  with  a  specified 
segment.  The  input  parameter  to  MMJTICKET  is  a  pointer  to  a 
segment's  handle. 

Initially,  MHJTICKET  locks  the  Global  Active  Segment  Ta¬ 
ble  to  prevent  a  race  condition.  Next  the  offset  of  the 
segment's  entry  into  the  G_AST  is  obtained  from  the  segment 
handle.  The  current  value  of  the  sequencer  for  the  speci¬ 
fied  segment  is  then  read  and  saved  as  a  return  parameter  to 
the  caller.  The  sequencer  value  is  then  incremented  in  an¬ 
ticipation  of  the  next  ticket  request.  Once  this  is  com¬ 
plete,  the  G_AST  is  unlocked  and  control  is  returned  to  the 
caller. 

4  •  aa_ui2S4i« 

The  HM. ALLOCATE  procedure  provided  in  this  implementa¬ 
tion  is  a  stub  of  the  NH_ALLOCATE  described  in  the  Memory 
Manager  design  of  Moore  and  Gary  £5].  The  primary  function 
of  MM_ALLOCATE  is  the  dynamic  allocation  of  fixed  size 
blocks  of  available  memory  space.  It  is  invoked  in  the  cur- 


rent  iapleaentation  by  the  initialization  routines  in 
BOOTSTBAP.LOADBB  and  TC.INIT  for  the  allocation  of  aeaory 
space  used  in  the  creation  of  the  Kernel  doaain  and  Supervi- 
sor  doaain  stack  segaents  and  the  creation  of  the  Known  Seg- 
aent  Tables  for  user  processes.  Dynaaic  reallocation  of 
previously  used  aeaory  space  (viz.,  garbage  collection)  is 
not  provided  by  the  ALLOCATE  stub  in  this  iapleaentation. 
All  aeaory  allocation  required  in  this  iapleaentation  is  for 
segaents  supporting  systea  processes  that  reaain  active,  and 
thus  allocated,  for  the  entire  life  of  the  systea.  aeaory 
is  allocated  in  blocks  of  256  (deciaal)  bytes  of  processor 
local  aeaory  (on-board  BAH) .  In  this  stub  allocatable  aeao¬ 
ry  is  declared  at  coapile  time  by  a  data  structure 
(HEH_POOL)  that  is  accessible  only  by  BH_ALLOCATE. 

The  input  paraaeter  to  BB_ALLOCATE  is  the  nuaber  of 
blocks  of  requested  aeaory.  This  paraaeter  is  converted 
froa  a  block  size  to  the  actual  nuaber  cf  bytes  requested. 
This  computation  is  made  siaple  since  aeaory  is  allocated  in 
powers  of  two.  The  byte  size  is  obtained  by  logically 
shifting  left  the  input  paraaeter  eight  tiaes,  where  eight 
is  the  power  of  two  desired  (viz. ,  256) .  Once  the  size  of 
the  requested  aeaory  is  coaputed,  it  is  necessary  to  deter- 
aine  the  starting  address  of  the  aeaory  block  (s)  to  be  allo¬ 
cated.  To  assist  in  this  coaputation,  a  variable 
(HEXT_BLOCK)  is  used  to  keep  track  of  the  next  available 
block  of  aeaory  in  HEM_POOL.  NEXT_BLOCK,  which  is  initial- 
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ized  as  zero,  provides  the  offset  into  the  aeaory  being  al¬ 
located.  Once  the  starting  address  is  obtained,  the  physi¬ 
cal  size  of  the  memory  allocated  is  added  to  MEIT_BLOCK  so 
that  the  next  request  for  aeaory  allocation  will  begin  at 
the  next  free  byte  of  aeaory  in  HEH_POOL.  This  new  value  of 
NEXT_BLOCK  is  saved  and  the  starting  address  of  the  aeaory 
for  this  request  is  returned  to  the  caller. 

d.  s&xs  KS2S51  aaaaLSS 

The  S&SS  Gate  Keeper  provides  the  logical  boundary  bet¬ 
ween  the  Supervisor  and  the  Kernel  and  isolates  the  Kernel 
froa  the  systea  users,  thus  aaking  it  tamperproof.  This  is 
accoaplished  by  aeans  of  the  hardware  systea/noraal  aode  and 
the  software  ring-crossing  aechanisa  provided  by  the  Gate 
Keeper.  The  Gate  Keeper  is  comprised  of  two  separate  mo¬ 
dules:  1)  the  USBBJ3ATE  module,  and  2)  the 
KERHELJSATE_KEBPEB  nodule.  These  aodules  are  disjoint,  with 
the  USEBJJATE  aodule  residing  in  the  Supervisor  domain  and 
the  KEBNEL_GATE_KEEPEB  module  residing  in  the  Kernel  doaain. 
It  is  important  to  note  that  the  (JSEB.GATE  is  a  separately 
linked  component  in  the  Supervisor  doaain  and  is  not  linked 
to  the  Kernel.  The  only  thing  in  common  between  these  two 
aodules  is  a  set  of  constants  identifying  the  valid  extended 
instruction  set  which  the  Kernel  provides  to  the  users. 

The  Gate  Keeper  aodules  presented  in  this  implementation 
are  only  stubs  as  they  do  not  provide  all  of  the  functions 
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required  of  the  Sate  Keeper.  However,  the  only  task  not 
provided  in  this  implementation  is  the  validation  of  parame¬ 
ters  passed  fros  the  Supervisor  to  the  Kernel.  A  detailed 
description  of  this  parameter  validation  design  is  provided 
by  Coleean  [2].  In  the  process  management  demonstration, 
the  supervisor  stubs  are  written  in  PLZ/ASH  with  all  parame¬ 
ters  passed  by  CPO  registers.  A  detailed  description  of  the 
Gate  Keeper  modules  and  the  nature  of  their  interfaces  is 
presented  below.  The  PLZ/ASH  source  listings  for  the  two 
Gate  Keeper  modules  are  provided  in  Appendix  0. 

i  •  g§§t_sai§  Miaii 

The  USEH_GATE  module  provides  the  interface  structure 
between  the  user  processes  in  the  Supervisor  domain  and  the 
Kernel.  The  US SEAGATE  is  comprised  cf  ten  procedures  (viz., 
entry  points)  that  correlate  on  a  one  to  one  basis  with  the 
ten  "user  visible"  extended  instructions  (listed  in  Figure 
10)  provided  by  the  Kernel.  The  only  action  performed  by 
each  of  these  procedures  is  the  execution  of  the  "system 
call"  instruction  (SC)  with  a  constant  value,  identifying 
the  particular  extended  instruction  invoked,  as  the  source 
operand. 

The  SC  instruction  is  a  system  trap  that  forces  the 
hardware  into  the  system  mode  (Kernel  domain)  and  loads  re¬ 
gister  15  with  the  system  stack  pointer  (Kernel  domain 
stack).  The  current  instruction  counter  value  (IC)  is 
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pushed  onto  the  Kernel  stack  along  with  the  current  CPU  flag 
control  word  (PCV) .  In  addition,  the  systea  trap  instruc¬ 
tion  is  pushed  onto  the  Kernel  stack  with  the  upper  byte 
representing  the  SC  instruction  and  the  lower  byte  repre¬ 
senting  the  SC  instruction's  source  operand  (viz.,  the  Ker¬ 
nel  extended  instruction  code) .  Together,  these  operations 
fora  an  interrupt  return  (IBET)  fraae  as  illustrated  in  Fig¬ 
ure  44.  Once  this  is  coaplete,  the  FCH  is  loaded  with  the 
PCS  value  found  in  the  Systea  Call  fraae  of  the  Prograa  Sta¬ 
tus  Area  (viz.,  the  hardware  "interrupt  vector").  The 
structure  of  the  Prograa  Status  Area  is  illustrated  in  Fig¬ 
ure  47.  The  instruction  counter  is  then  loaded  with  the  ad¬ 
dress  of  the  SC  instruction  trap  handler.  This  value  is 
also  located  in  the  SC  fraae  of  the  Prograa  Status  Area. 
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Figure  47:  Program  Status  Area 
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2.  Eacaal_S4is_5si£S£  Sfldala 

The  system  trap  handler  for  the  Systea  Call  instruction 
is  the  KEEN  EL_G1TE_KEBPEB .  The  address  of  the 
KEBHELjiATE_KEEPEB  and  the  Kernel  FCH  value  are  placed  in 
the  System  Call  fraae  of  the  Program  Status  Area  by  the 
BOOTSTB4P.LOADEB  aodule  during  initialization.  The 
KEBHEL_GATE_KEEPEB  fetches  the  extended  instruction  code 
froa  the  trap  instruction  entry  in  the  IBET  fraae  on  the 
Kernel  stack.  This  value  is  then  decoded  by  a  "case1*  state- 
aent  to  deteraine  which  extended  instruction  is  to  be  exe¬ 
cuted.  If  the  extended  instruction  code  is  valid,  the  ap¬ 
propriate  Kernel  procedure  is  invoked.  Otherwise,  an  error 
condition  is  set  and  no  Kernel  procedures  are  not  invoked. 
Once  control  returns  to  the  KEBMEL_GATB_KEEPEB,  the  CPD  re¬ 
gisters  and  noraal  stack  pointer  (NSP)  value  are  pushed  onto 
the  Kernel  stack  in  preparation  for  return  to  the  Supervisor 
doaain.  It  is  noted  that  this  operation  would  normally  oc¬ 
cur  immediately  upon  entry  into  the  KERNEL_GA TE_K EEPEfi .  In 
this  iapleaentation,  however,  paraaeter  validation  is  not 
accoaplished  and  the  CPU  registers  are  used  to  pass  paraae- 
ters  to  and  froa  the  Kernel  only  for  use  by  the  process  aan- 
ageaent  demonstration.  In  an  actual  SASS  environment:,  all 
paraaeters  would  be  passed  in  a  separate  arguaent  list  and 
the  CPU  registers  would  appear  exactly  the  saae  upon  leaving 
the  Kernel  as  they  did  upon  entering  the  Kernel.  This  is 
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important  to  insure  that  no  data  or  information  is  leaked 
from  the  Kernel  by  means  of  the  CPO  registers. 

Control  is  returned  to  the  Supervisor  by  means  of  the 
return  mechanism  in  the  hardware  preempt  handler.  This  me* 
chanism  is  utilized  to  preclude  the  necessity  of  building  a 
separate  mechanism  for  the  KERHEL_GATE_KEEPER  that  would  ac¬ 
tually  perform  the  very  same  function.  To  accomplish  this, 
the  KEBHEL_GATE_KEEPER  executes  an  unconditional  jump  to  the 
PREEHPT_RET  label  in  PHYS_PREEdPT_B ARDLSR.  This  "jump"  to 
the  hardware  preempt  handler  represents  a  "virtual  IRET"  in¬ 
struction  providing  the  same  function  as  the  virtual  inter¬ 
rupt  return  described  in  the  discussion  of  the  virtual 
preeapt  handler.  At  this  point,  the  virtual  preempt  inter¬ 
rupts  are  unmasked,  the  normal  stack  pointer  and  CPU  regis¬ 
ters  are  restored  from  the  stack,  and  control  is  returned  to 
the  Supervisor  by  execution  of  the  IRET  instruction. 

e.  snaaisx 

The  implementation  of  process  management  functions  for 
the  SASS  has  been  presented  in  this  chapter.  The  implemen¬ 
tation  was  discussed  in  terms  of  the  Event  Manager,  Traffic 
Controller,  Distributed  Memory  Manager,  and  Gate  Keeper  mo¬ 
dules. 
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Chapter  XXIII 
COHCLOSIOK 

The  implementation  of  process  management  for  the  securi¬ 
ty  Kernel  of  a  secure  archival  storage  system  has  been  pre¬ 
sented.  The  process  aanageaent  functions  presented  provide 
a  logical  and  efficient  aeans  of  process  creation*  control* 
and  scheduling.  In  addition*  a  siaple  but  effective  mechan- 
ism  for  inter-prccess  coaaunication*  based  on  the  eventcount 
and  sequencer  priaitives,  vas  created.  HorJc  was  also  coa- 
pleted  in  the  area  of  Kernel  database  initialization  and  a 
Gate  Keeper  stub  to  allow  for  dual  domain  operation. 

The  design  for  this  iapleaentation  was  based  on  the  Zi- 
log  Z8001  sixteen  bit  segaented  microprocessor  [22]  used  in 
conjunction  with  the  Zilog  Z8010  Memory  Management  Unit 
[23].  The  actual  iapleaentation  of  process  management  for 
the  SASS  was  conducted  on  the  Advanced  Micro  Computers 
Aa96/4116  MonoBoard  computer  [1]  featuring  the  AmZ8002  six¬ 
teen  bit  non-segaented  microprocessor.  Segmentation  hard¬ 
ware  was  siaulated  by  a  software  Meaory  Management  Unit  la- 
age. 

This  iaplenentat'ion  was  effected  specifically  to  support 
the  Secure  Archival  Storage  Systea  (SASS)  [17].  However, 
the  iapleaentation  is  based  on  a  faaily  of  Operating  Systems 
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(7]  designed  vith  a  primary  goal  of  providing  aultilevel  in¬ 
formation  security.  The  loop  free  modular  design  utilized 
in  this  implementation  easily  facilitates  any  required  ex¬ 
pansion  or  modification  for  other  family  members.  In  addi¬ 
tion,  this  implementation  fully  supports  a  multiprocessor 
design.  While  the  process  management  implementation  appears 
to  perform  correctly,  it  has  not  been  subjected  to  a  formal 
test  plan.  Such  a  test  plan  should  be  developed  and  imple¬ 
mented  before  kernel  verification  is  begun. 

A.  ZQ1LQW  OH  WORK 

There  are  several  possible  areas  in  the  SASS  design  that 
would  be  immediately  suitable  for  continued  research.  In 
the  area  of  hardware,  this  includes,  the  establishment  of  a 
multiprocessor  environment,  hardware  initialization,  and  in¬ 
terfacing  to  the  host  computers  and  secondary  storage. 
Further  work  in  the  Kernel  includes  the  actual  implementa¬ 
tion  of  the  memory  manager  process,  and  the  refinement  of 
the  Gate  Keeper  and  Kernel  intialization  structures.  The 
implementation  of  the  Supervisor  has  not  been  addressed  to 
date.  Its  areas  of  research  include  the  implementation  of 
the  File  Manager  and  Input/Output  processes,  and  the  final 
design  and  implementation  of  the  SASS-Hosts  protocols. 

Other  areas  that  could  also  prove  interesting  in  rela¬ 
tion  to  the  SASS  include  the  implementation  of  dynamic  memo¬ 
ry  management,  the  support  of  multilevel  hosts,  dynamic  pro- 
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Appendix  A 

EVENT  MANAGER  LISTINGS 


Z8000 ASM  2.02 

LOC  OBJ  CODE  ST NT  SOURCE  STATEMENT 
SLISTON  $TTY 


EVENT  MGR  MODULE 


CONSTANT 

TRUE  : =  1 

PALSE  :=  0 

READ_ACCESS  :»  1 

WRITE  ACCESS  :*  0 

SUCCEEDED  :*  2 

SEGMENT  NOT  KN08N  :»  28 

ACCESS  CLASS  NOT  EQ  : -  33 

ACCESS  CLASS  NOT  GE  :=  41 

KST  SEG  NO  i~  2 

NR  OPJCSEGS  : =  10 

MAX  NO_KST_ENTRIBS  : =  54 

NOTJCNOWN  ;»  IFF 

TYPE 

H_ARB  AY  ARE  AY[  3  WORD] 


KST_REC  RECORD 
[MM  HANDLE  H  ARRAY 

SIZE  WORD 

ACCESS  MODE  BYTE 

IN  CORE  BITE 

CLASS  LONG 

M  SEG  NO  SHORT.INTEGER 

ENTRY  NUMBER  SHORT  INTEGER] 


EXTERNAL 
MM  TICKET 

MH_READ_EVENTCOUNT 

TC~ AD VANCE 

TC  AWAIT 

PROCESS  CLASS 

CLASS_EQ 

CLASSJ3E 

ITC  GET  SEG  PTR 


PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 
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INTERNAL 

{SECTION  EM_AST_ DCL 
!  NOT £;  THIS  SECTION  IS  AN  "OVEBLAI* 

OS  "FRAME"  USED  TO  DEFINE  TBS 
FORMAT  OF  THE  AST.  NO  STORAGE  IS 
ASSIGNED  BUT  BATHES  THE  AST  IS 
STOBED  IN  A  SEPABATELI  OBTAINED 
AHEA.  (A  SEGMENT  SBT  ASIDE  FOB  IT )1 

SABS  0 

0000  AST  ABaAr(NAX_NOJCST_BNTHIES  KST.BEC  ] 
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MBSaSSBE* 


GLOBAL 

{SECTION  EH  GLB_PROC 


0000 

BEAD 

{ ******* 

*  BEADS 

PROCEDURE 

SPECIFIED  EVENTCOUNT  * 

*  AND  BETORNS  IT'S  VALUE  TO 

* 

*  THE  CALLEB 

* 

****************************** 

*  PARAMETERS: 

* 

*  B1 : 

SEGMENT  # 

* 

*  B2: 

INSTANCE 

* 

****************************** 

*  BETUBNS : 

* 

*  RO: 

SUCCESS  CODE 

* 

*  BB4 : 

EVENTCOUNT 

* 

****************************** ! 

ENTRY 

!  SAVE 

INSTANCE  ! 

0000 

93P2 

POSH 

1R15,  &2 

!  "BE AD"  ACCESS  REQUIRED  ! 

0002 

2102 

LD 

R2,  #READ_ACCESS 

0004 

0001 

1  GET 

SEG  HANDLE  &  VERIFY 

ACCESS  ! 

0006 

5P00 

CALL 

CON VERT_AND_V SHIFT 

! B1: SEG  • 

0008 

0000* 

R2: REQ.  ACCESS 
RETURNS: 
RO:SUCCESS  CODE 
B1: HANDLE  PTR ! 

000A 

OBOO 

CP 

BO,  #S UCCBEDED 

OOOC 

0002 

IF  EQ 

! ACCESS  PERMITTED! 

OOOE 

5EQE 

THEN 

! BEAD  EVENTCOUNT! 

0010 

001C' 

IRESTORE  INSTANCE! 

0012 

97  F2 

POP 

R2,  8R15 

0014 

5P00 

CALL 

MM_READ_E VENTCOUNT 

!  3 1 :  HPTR 

0016 

1000* 

32: INSTANCE 
RETURNS: 
RO:SUCCESS  CODE 
BR4: EVENTCOUNT! 

0018 

5E08 

ELSE 

IRESTORE  SP! 

00 1 A 

00  IE' 

001C 

97P2 

POP 

B2,  8R 1 5 

PI 

00  IE 

9E08 

BET 

0020 

END  BEAD 
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0020 


TICKET 


PBOCEOOBE 


I  **************************** 

*  RETURNS  CURRENT  VALUE  OP 

*  TICKET  TO  CALLEB  AND  INCRE 

*  BENTS  SEQUENCER  FOB  NEXT 

*  TICKET  OPEBATION 

********************* *******1 

*  PABAHETEBS: 

*  Bit  SEGBENT  • 

**************************** 

*  RETURNS: 

*  ROt  SUCCESS  CODE 

*  BB4:  TICKET  VALUE 


! 


0020  2102 
0022  0000 
0024  SFOO 
0026  0000* 


0028  OBOO 
002A  0002 

002C  5E0E 
002E  0038* 
0030  5F00 
0032  0000^ 


0034  2100 
0036  0002 

0038  9E08 
003A 


ENTRY 

!  GET  SEG  HANDLE  6  VERIFY  ACCESS  ! 
!  "WRITE"  ACCESS  REQUIRED  t 


LD 

R2,  VHBITE.ACCESS 

CALL 

CONVERT_AND_ VERIFY 

! B 1 : SEG  * 

CP 

RO,  tSUCCEEDED 

B2: ACCESS 
RETURNS: 

RO :SUCCESS 
B1: HANDLE 

BEQ 

CODE 

PTB! 

IF  EQ 
THEN 

! ACCESS  PERHITTED! 

!  GET  TICKET  ! 

CALL  HB  TICKET  IB1:  HANDLE  PTB 


RETURNS: 
RB4: TICKET! 

!  RSTOBE  SUCCESS  CODE  ! 

LD  BO,  * SUCCEED ED 


FI 

RET 

END  TICKET 
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0031  AWAIT  PROCEDURE 

I  ******************************* 

*  COR BENT  EVENTCOUNT  VALUE  IS  * 

*  COMPARED  TO  USEE  SPECIFIED  * 

*  VALUE.  IF  USEE  VALUE  IS  * 

*  SBEATEB  THAU  CURRENT  EVENT-  * 

*  COUNT  VALUE  THEN  PROCESS  IS  * 

*  "BLOCKED"  UNTIL  THE  DESIRED  * 

*  EVENT  OCCURS.  * 

******************************* 

*  PARAMETERS:  * 

*  R1 :  SEGMENT  *  * 

*  R2:  INSTANCE  (EVENT  *)  • 

*  RR4 :  SPECIFIED  VALUE  * 

******************************* 

*  RETURNS:  * 

*  RO:  SUCCESS  CODE  * 

******************************* 1 


003 A  91F4 

003C  93F2 

003E  2102 
0040  0001 

0042  5FOO 
0044  0000* 


0046  OBOO 
0048  0002 

004A  5E0E 
004C  005A' 

004E  97F2 

0050  95F4 
0052  5F00 
0054  0000* 


ENTRY 

1  SAVE  DESIRED  EVENTCOUNT  VALUE  ! 

PUSHL  SRI  5,  RR4 
I  SAVE  INSTANCE  ! 

PUSH  SR15,  R2 
!  "READ"  ACCESS  REQUIRED  ! 

LD  R2«  #READ_ACCESS 

!  GET  SEG  HANDLE  S  VERIFY  ACCESS  ! 

CALL  CONVE8T.AND.VERIFY  !R1:SEG  # 

R2: ACCESS  REQ 
RETURNS: 

RO : SUCCESS  CODE 
R1:HANDLE  PTB ! 

CP  RO,  iSUCCEEDED 

IF  EQ  !  ACCESS  PERMITTED  i 
THEN  i  AWAIT  EVENT  OCCURRENCE  ! 

!  RESTORE  INSTANCE  t 
POP  R2,  SR  15 

!  RESTORE  SPECIFIED  VALUE  I 
POPL  RR4 ,  SR  15 

CALL  TC.AWAIT  ! R 1 : HANDLE  PTB 

R2: INSTANCE 
RB4 : VALUE 
RETURNS: 

RO: SUCCESS  CODE  1 
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0056  5E08  ELSE  IBESIOBE  SUCK! 
0058  005E* 

005A  95F4  POPL  RB4 ,  8B15 

005C  97P2  POP  82,  *B15 

PI 

005E  9E08  BET 
0060  EMO  AWAIT 
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0060  ADVANCE  PROCEDURE 

•  ************** ***************** 

*  SIGNALS  THE  OCCURRENCE  OF  * 

*  SONS  EVENT.  EVENTCOUNT  IS  * 

*  INCREMENTED  AND  THE  TBAFFIC  * 

*  CONTBOLLEB  IS  INVOKED  TO  * 

*  AWAKEN  ANT  PROCESS  AWAITING  * 

*  THE  OCCUBRENCE.  * 

******************************* 

*  PABAHETEBS:  * 

*  Hit  SEGMENT  *  * 

*  B2:  INSTANCE  (EVENT  *)  * 

******************************* 

*  BETORNS:  * 

*  BO:  SUCCESS  CODE  * 

*******************************1 

ENTRY 

t  SAVE  INSTANCE  ! 

0060  93F2  POSH  9815,  B2 

!  GET  SEG  HANDLE  6  VEBIFY  ACCESS  1 
1  "WRITE"  ACCESS  BEQUIBED  1 
0062  2102  LD  B2,  #WRITE  ACCESS 

0064  0000 

0066  5FOO  CALL  CONVERT., AND  VERIFY  !B1:SEG  * 

0068  0000* 

B2: ACCESS  BEQ 
RETURNS: 

BO: SUCCESS  CODE 
B1:HANDLE  PTB! 

006 A  0B00  CP  BO,  tSQCCEEDED 

006C  0002 

IF  EQ  !  ACCESS  PEBMITTED  ! 

006E  5E0E  THEN  !  ADVANCED  EVENTCOONT  1 
0070  007C* 

!  BESTOBE  INSTANCE  1 
0072  97F2  POP  R2,  9B15 

0074  SFOO  CALL  TC_AD VANCE  I  HI: HANDLE  PTB 

0076  0000* 

B2:INSTANCE 

BETOBNS: 

BO :SOCCESS  CODEI 

0078  5E08  ELSE  ! RESTORE  STACK t 

007A  007B* 

007C  97F2  POP  B2,  *R15 

FI 
RET 

END  ADVANCE 


007E  9E08 
0080 


INTERNAL 

{SECTION  EE  INT  PROC 


0000  C0N7ERT_ANDjrEBIPT  PROCEDURE 

j  *************************************** 

*  CON7ERTS  S EGBERT  ROBBER  TO  KST  INDEX* 

*  AND  EXTRACTS  SEGBERT* S  HANDLE  FROM  * 

*  KST.  IF  SUCCESSFUL,  THEN  ACCESS  * 

*  CLASS  OF  SUBJECT  IS  CHECKED  AGAINST  * 

*  ACCESS  CLASS  OF  OBJECT  TO  INSURE  * 

*  THAT  ACCESS  IS  PSRBITTED.  * 

*************************************** 

*  PARAHETEBS:  * 

*  R1:  SEGBENT  ROBBER  * 

*  R2:  ACCESS  REQUESTED  * 

*************************************** 

*  RETURNS:  * 

*  RO:  SUCCESS  CODE  * 

*  R1 :  HANDLE  POINTER  * 

*********************** ****************} 


0000  93F2 

0002  5F00 
0004  0062* 


0006  OBOO 
0008  0002 

OOOA  5E0E 
OOOC  005E* 

OOOE  91P4 

0010  5F00 
0012  0000* 


0014  95F0 

0016  1414 

0018  97F1 

001A  93F0 

001C  0B01 
00 IE  0000 


ENTRY 

!  SA7E  REQUESTED  ACCESS  I 
PUSH  9R15,  32 
!  GET  SEGBERT  HANDLE  ! 

CALL  GET.HARDLE  !R1:SEG  * 

RETURNS: 

HG:SUCCESS  CODE 
34 : HANDLE  PTR 
35  :CLA5S  PTR! 

CP  RO,  ISUCCEEDED 

IF  EQ  !  SEGBERT  IS  KROHH  ! 

THEN  !  7ERIFT  ACCESS  ! 

!  SA7E  HANDLE  &  CLASS  PTR  ! 

PUSHL  9315,  RR4 
!  GET  SUBJECT'S  SAC  ! 

CALL  PROCESS.CLASS  ! RETURNS: 

RR2:PR0C  CLASS! 

!  3ETRIE7E  SEG  CLASS  POINTER  ! 

POPL  RRO,  9R1 5 
!  GET  SEGBERT* S  CLASS  I 
LDL  RR4,  9R1 

!  RETRIE7E  REQUESTED  ACCESS  ! 

POP  R1 ,  9R15 
!  SA7E  HANDLE  POINTER  ! 

PUSH  9R15,  RO 
!  CHECK  ACCESS  CLEARANCE  ! 

CP  R1 ,  # WRIT E_ACC ESS 

IF  EQ  !  WRITE  ACCESS  REQUESTED  1 
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THEM 


0020  5E0E 
0022  0040* 

0024  5P00  CALL  CLASS.BQ  !EB2:PBOCESS  CLASS 

0026  0000* 

BB4: SEQUENT  CLASS 
BETOBMS: 

B1 :  CONDITION  CODE! 

0028  0B01  CP  B1 (  tPALSE 

002A  0000 

I?  EQ  ! ACCESS  NOT  PERMITTED! 

002C  520E  THEN 

002E  0038* 

0030  2100  LD  HO,  #ACCESS_CLASS _NOT_EQ 

0032  0021 

0034  5808  ELSE  {ACCESS  PEBMITTEDI 

0036  QQ3C* 

0038  2100  LD  HO,  •SUCCEED ED 

003A  0002 

PI 

003C  5E08  ELSE  !  BEAD  ACCESS  REQUESTED  ! 

003E  0058' 

0040  5P00  CALL  CLASS.GE  !BB2:PBOCESS  CLASS 

0042  0000* 

BB4: SEGMENT  CLASS 
BBTUBNS: 

B1 : CONDITION  CODE1 

0044  0B01  CP  B1,  *PALSE 

0046  0000 

IF  EQ  {ACCESS  NOT  PEBMITTEDI 
0048  5E0E  THEN 

004A  0054' 

004C  2100  LD  BO,  #ACCESS_CLASS _N0T_GE 

004E  0029 

0050  5E08  ELSE  {ACCESS  PEBMITTEDI 

0052  0058* 

0054  2100  LD  BO,  #SUCCBEDED 

0056  0002 

PI 

PI 

!  RETRIEVE  HANDLE  POINTEB  ! 

0058  97F1  POP  B1,  9B15 

005A  5E08  ELSE 

005C  0060* 

{  RESTORE  STACK  ! 

005E  97P2  POP  R2 ,  9B15 

PI 

0060  9E08  RET 

0062  END  CONVERT  AND  VERIFY 
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0062  GETJiANDLE  PROCEDURE 

| ******************************* 

*  CONVERTS  SEGMENT  NUMBER  TO  * 

*  KST  INDEX  AND  DETERMINES  IF  * 

*  SEGMENT  IS  KNOHN.  IF  KNOWN  * 

*  POINTER  TO  SEGMENT  HANDLE  * 

*  AND  POINTER  TO  SEGMENT  CLASS* 

*  ARE  RETURNED.  * 

******************************* 

*  PARAMETERS:  * 

*  R1 :  SEGMENT  NUMBER  * 

******************************* 

*  RETURNS:  * 

*  RO:  SUCCESS  CODE  * 

*  R4 :  HANDLE  POINTER  * 

*  H5 :  CLASS  POINTER  * 

*******************************1 

ENTRY 

i  CONVERT  SEGMENT  *  TO  KST  INDEX  #  1 


0062 

0301 

SUB 

81,  #NR_OF_KSEGS 

0064 

000A 

!  VERIFY  KST  INDEX  ! 

0066 

2100 

LD 

RO,  iSUCCEBDED 

0068 

0002 

006  A 

0B0 1 

CP 

HI,  *0 

006C 

0000 

IF  LB 

I  INDEX  NEGATIVE! 

006E 

5E0A 

THEN 

0070 

007A* 

0072 

2100 

LD 

RO,  ♦SEGMEHT_NOT_KNOHN 

0074 

001C 

0076 

5E08 

ELSE 

! INDEX  POSITIVE! 

0078 

0086' 

007A 

0B0 1 

CP 

R 1 ,  #SAX_NO_KST_EN TRIES 

007C 

0036 

IF 

GT  1  EXCEEDS  MAXIMUM  INDEXI 

007E 

5E02 

THEN  ! INVALID  INDEXi 

0080 

0086* 

0082 

2100 

LD  RO.  #SBG  MENTNOT  KNOHN 

0084 

00 1C 

FI 

FI 

0086 

0B00 

CP 

RO,  ^SUCCEEDED 

0088 

0002 

IF  EQ 

! INDEX  VALID! 

008A 

5E0E 

THEN 

008C 

OOBE* 

!  SAVE  KST  INDEX  ! 

008E  93F1  PUSH  8R15,  R1 

!  GET  KST  ADDRESS  ! 

0090  2101  LD  HI,  #KST  SEG  NO 

0092  0002 

0094  5F00  CALL  ITC_GET_SEG_PTR  !R1:  KST_SEG_NO 
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0096  0000* 


RETURNS : 

BO : KST  ADDB! 

I  RETRIEVE  KST  INDEX  #  ! 

0098  97F3  POP  R3,  SB15 

!  CONVEBT  KST  INDEX  *  TO  KST  OFFSET  1 
009A  1902  HOLT  RR2,  tSIZEOF  KST.BEC 

009C  0010 

!  COHPOTE  KST  ENTRY  ADDRESS  ! 

009E  8103  ADD  R3,  RO 

!  SEE  IF  SEGHENT  IS  KNOBN  i 
00 AO  4031  CP  KST. H  SEG_NO  (B3)  ,  INOT  KNOWN 

00A2  000E 
00A4  OOPP 

IF  EQ  ! SEGHENT  NOT  KNOBN 1 
00A6  5E0E  THEN 

00A8  00B2* 

OOAA  2100  LD  RO,  #SEG HE NT_NOT_KNOBN 

00 AC  001C 

00 AE  5E08  ELSE  ISEGHENT  KNOHNi 

OOBO  OOBE* 

00B2  2100  LD  ROf  iSOCCEEDED 

00B4  0002 

!  GET  HANDLE  POINTER  ! 

00B6  7634  LDA  B4,  KST. HH  HANDLE (B3) 

00B8  0000 

!  GET  CLASS  POINTER  ! 

OOBA  7635  LDA  R5,  KST. CLASS (R3) 

OOBC  OOOA 

FI 

FI 

OOBE  9E08  BET 
OOCO  END  GET_H ANDI.E 

END  EVENT  MGR 


Appendix  B 

TRAFFIC  CONTROLLER  LISTINGS 

Z8000ASM  2.02 

LOC  OBJ  COOS  ST NT  SOURCE  STATENENT 

SLISTON  STTY 
TC  NODOLE 


CONSTANT 


SYSTEM  PARAMETERS  ********  ! 


NR  PROC 

•  3 

4 

VP~NR 

•  * 

2 

nr”cpu 

•  at 

2 

nr”kst 

•  ss 

54 

(  ********  SYSTEM  CONSTANTS  ********  ! 


RUNNING 
READY 
BLOCKED 
IDLE  PROC 
NIL 

INVALID 
KERNEL_STACK 
USER  STACK 
KST  S  EG 

kstIlihit 

USES  FCW 
WRITE 


0 

1 

2 

AD  ODD 
SFFFF 
SB  SEE 
1 
3 
2 
1 

SI  800 
0 


{INDICATES  LOWEST  SYSTEM 
SECURITY  CLASS! 


SYSTEM_LOW 

STK  OFFSET 

REMOVED 

TRUE 

FALSE 

SUCCEEDED 


0 

SFF 

SABCD 

1 

0 

2 


TYPE 
AP_PTR 
VP  PTR 
ADDRESS 
M  ARRAY 


WORD 
WORD 
WORD 
ARRAY[  3 


WORD] 
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AP  TABLE  RECORD 


f  NEXT  AP  AP  PTB 

DBB 

WORD 

SAC 

LONG 

PRI 

INTEGER 

STATE 

INTEGER 

AFFINITY  WORD 

VP  ID 

y  p_ptb 

HANDLE 

H  ARRAY 

INSTANCE  WORD 

7AL0E 

LONG 

PILL  2 

] 

ARRAI[2  WORD] 

R  UN_ARR AI 

ARRAI[7P_NR  AP_PTR] 

RDI  ARRAI 

ARRAI£NR  CPU  AP  PTR  ] 

AP  DATA 

ARRAIf NR  PROC  AP  TABLE] 

YP  DATA 

RECORD 

f NR  YP 

ARRAI[  NR  CPU  WORD] 

FIRST 

ARRAI[ NR_CPU  VP..PTB  ] 

1 

KS?_REC 
[as  HANDLE 
SIZE 
ACCESS 
IN  CORE 
CLASS 
N  SEG  NO 
ENTRT  NON 

] 

EXTERNAL 


K  LOCK 

PROCEDURE 

K  UNLOCK 

PROCEDURE 

sIt  preehpt 

PROCEDURE 

SWAP  YDBR 

PROCEDURE 

IDLE 

PROCEDURE 

RUNNING^, VP 

PROCEDURE 

CREATE  INT  VEC 

PROCEDURE 

LIST_INSERT 

PROCEDURE 

ALLOCATE  HHU 

PROCEDURE 

nh.allocIte 

PROCEDURE 

UPDATE  N  HU  IMAGE 

PROCEDURE 

create'stack 

PROCEDURE 

HH_ ADVANCE 

PROCEDURE 

MM  READ  EVENTCOUNT 

PROCEDURE 

G  AST  LOCK 

WORD 

PREEMPT  RET 

LABEL 

RECORD 

H_  ARRAY 

WORD 

BITE 

BITE 

LONG 

SHOBT.INTEGER 
SHORT  INTEGER 
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0000 


oo&o 

00A2 


0000 


0000 


0000 


SSECTION  TC_DATA 
INTERN  AL 

APT  RECOHO 

[  LOCK 

RUNNING  LIST 
READY  LIST 
BLOCKED  LIST 
PILL  3 
?P 

PILL 

AP 

1 


WORD 

RUM  ARRAY 

RDY.ARRAY 

AP  PTR 

LONG 

VP  DATA 

ARB  AX £  4  WORD] 

AP  DATA 


ITHBSB  VARIABLES  ARE  USED  DOBING  TC 
INITIALIZATION  TO  SPECIE!  AVAILABLE 
ENTRIES  IN  THE  APT,  AND  ARE  INITIAL¬ 
IZED  BY  TC_INIT  IN  THIS  IMPLEMENTATION! 
NEXT_VP  NORD 
APT  ENTRY  NORD 


$ SECTION  TCLOCAL 


SABS  0 

! NOTE :  USED  AS 
ARG  LIST 
[REG 
IC 

CPU  ID 
SAC1 

pan 

USR.STK 

KER_STK 

kstT 


OVERLAY  ONLY! 
RECORD 

ARRAY£  13  NORD] 

NORD 

NORD 

LONG 

NORD 

NORD 

NORD 

LONG 


] 


SABS  0 

! NOTE:  USED  AS  STACK  FRAME  FOB 
STORAGE  OP  TEMPORARY  VARIABLES 
FOB  CREATE  PROCESS.! 

CREATE  RECORD 

£  ARG  PTR  NORD 

DBR  NON  NORD 

LIMITS  NORD 

SEG  ADDR  ADDRESS 
N  S~P  NORD 

1  ”  “ 


SABS  0 

HANDLS.VAL  RECORD 
[HIGH  LONG 
LON  NORD 

] 


! THE  FOLLOHING  DECLARATION  IS  UTILIZED 
AS  A  STACK  FRAME  FOB  STORAGE  OF 
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0000 


0000 


TEMPORARY  VARIABLES  UTILIZED  BY 


TC  ADVANCE  AND 

TC_AH  AIT 

SABS  0 

TEMP  RECORD 

[HANDLE_PTR 

HORD 

EVENT_NR 

WORD 

evemt'val 

LONG 

ID  VP~ 

HORD 

CPU  NUM 

HORD 

HANDLE  HIGH 

LONG 

HANDLE  LON 

HORD 

] 

$  SECTION  TC.KSTJJCL 
1  NOTE:  KST  DECLARATION  IS  USED  HERE 
TO  SUPPORT  KST  INITIALIZATION  FOR 
THIS  DEMONSTRATION  ONLY.  THIS 
DECLARATION  AND  INITIALIZATION 
SHOULD  EXIST  AT  THE  SEGMENT  MANAGER 
LEVEL  AND  THUS  SHOULD  BE  BEHOVED 
UPON  IMPLEMENTATION  OF  SYSTEM 
INITIALIZATION. ! 

SABS  0 

KST  AHRAT£NR  KST  KST.REC] 
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♦ 


0000 


SSECTION  TC_INT_PROC 

TC  GETWORK  PROCEDURE 

i  ***************************** 

*  PROVIDES  GENERAL  BA RAGE-  • 

*  BENT  OF  OSES  PROCESSES  BY  * 

*  EFFECTING  PROCESS  SCHEDU-  * 

*  LING  ON  VIRTUAL  PROCESSORS* 


*  PARABETERS: 

*  R1:  CURRENT  VP  ID 

*  R3:  LOGICAL  CPU  # 


*  LOCAL  VARIABLES:  * 

*  R2:  NEXT  READY  PROCESS  * 

*  R4:  AP  PTR  * 

*****************************! 

ENTRY 

!  FIND  FIRST  READY  PROCESS  1 
0000  6132  LD  R2#  APT. READY  LIST  (R3) 

0002  0006* 

GET  READY  AP: 

DO  ! WHILE  NOT  (END  OF  LIST  OR  READY)! 
0004  0B02  CP  R2,  ANIL 
0006  FFFF 

0008  5E0E  IF  EQ  I  NO  READY  PROCESS!  THEN 
OOOA  0010* 

000C  5E08  EXIT  FROB  GET  READY  AP 

000E  0026* 

FI 

0010  4D21  CP  APT. AP. STATE  (R2)  ,  AREADY 

0012  002A* 

0014  0001 

0016  5E0E  IF  EQ  ! PROCESS  READY!  THEN 
0018  00 IE' 

00 1 A  5E08  EXIT  FROB  GET  READY  AP 

00 1C  0026* 

FI 

!  GET  NEXT  AP  FROB  LIST  i 
00 IE  6124  LD  R4,  APT. AP. NEXT  AP  (R2) 

0020  0020' 

0022  A142  LD  R2,  R4 

0024  E8EF  OD 

0026  0B02  CP  R2 , ANIL 

0028  FFFF 

002A  5E0E  IF  EQ  I  IF  NO  PROCESSES  READY  1  THEN 

002C  003C' 

!  LOAD  IDLE  PROCESS  ! 

002E  4D15  LD  APT. RUNNING  LIST(RI),  AIDLE  PROC 

0030  0002* 

0032  DDDD 

0034  5F00  CALL  IDLE 

0036  0000* 

0038  5E08  ELSE 
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003A  0052' 


I  LOAD  FIRST  READY  AP  ! 


003C 

003S 

6F12 

0002* 

LD 

APT. BUN NING_LIST  (R1)  ,  R2 

0040 

0042 

0044 

4D25 

002A* 

0000 

LD 

APT.  AP.  STATE  (R2)  ,  ♦RUNNING 

0046 

0046 

6F21 

002E* 

LD 

APT.  AP.  VP_ID(R2)  ,  R1 

004A 

004C 

6121 

0022* 

LD 

HI,  APT . AP. DBR  (R2) 

004E 

0050 

5F00 

0000* 

CALL 

FI 

SHAP.TDBR  !  (R  1:  DBR)  1 

0052 

9E08 

RET 

0054 

END  TC_ 

GET WORK 
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0054  VIRTUAL  PREENPT_H ANDLER  PROCEDURE 

1 I************************** 

*  LOADS  FIRST  READT  AP  * 

*  IN  RESPONSE  TO  PREEMPT  * 

*  INTERRUPT  * 

***************************( 

ENTRY 

!**  CALL  HAIT_LOCK  (APT-.. LOCK)  **! 

!**  RETURNS  HHEN  PROCESS  HAS  LOCKED  APT  **1 
0054  7604  LDA  R4,  APT. LOCK 

0056  0000* 

0058  5F00  CALL  K  LOCK 

005A  0000* 

1  GET  RUNNING  VP  ID  ! 

005C  5P00  CALL  RUNNING  VP  JREIURNS: 

005E  0000* 

R1: VP  ID 
R3: CPU  *! 

!  GET  AP  ! 

0060  6112  LD  R2,  APT. RUNNING  LIST(RI) 

0062  0002* 

!  IF  NOT  AN  IDLE  PROCESS,  SET  IT  TO  READY  ! 
0064  0B02  CP  R2,  #IDLE_PROC 

0066  DDDO 

0068  5E06  IF  NE  !  NOT  IDLE  l  TEEN 
006A  0072' 

006C  4D25  LD  APT. AP. STATE (R2) ,  #READY 

006E  002A* 

0070  0001 

FI 

!  LOAD  FIRST  READY  PROCESS  ! 

0072  5F00  CALL  TC_GETHORK  !R1:VP_ID 
0074  0000* 

R3 :CPU  #( 

! NOTE:  THIS  IS  THE  INITIAL  POINT  OF 
EXECUTION  FOR  USER  PROCESSES.! 

VIRT  PREEHPT  RETURN: 

!**  CALL  UNLOCK  (APT-. LOCK)  **! 

!**  RETURNS  WHEN  PROCESS  HAS  UNLOCKED  APT  **! 
!**  AND  ADVANCED  ON  THIS  EVENT  **! 

0076  7604  LDA  R4,  APT. LOCK 

0078  0000* 

007A  5F00  CALL  K.UNLOCK 

007C  0000* 

!  PERFORM  A  VIRTUAL  INTERRUPT  RETURN  ! 

.'NOTE:  THIS  JUMP  EFFECTS  A  VIRTUAL 
IRET  INSTRUCTION.! 

007B  5E08  JP  PREEMPT.RET 

0080  0000* 
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0082 


END  VI&T(J&L_PREEHPT_HiNDLEB 
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GLOBAL 

SSECTIOH  TC.GLB.P  HOC 

oooo  tc  inn  “  procedure 

j  ***************************** 

*  INITIALIZES  APT  HEADER  * 

*  AND  VIRTUAL  INT  VECTOR  * 

****** ************* ********** 

*  PARAMETERS:  * 

*  R1:  CPU  ID  * 

*  R2:  NR.VP  * 

************«.****************{ 

ENTRY 

!  NOTE'  THt  NEXT  POUR  VALUES  ARE 
ONLY  TO  BE  INITIALIZED  ONCE.  ! 


0000 

0002 

0004 

4D05 

00  AO' 
0000 

LD 

«H?I?JFP,  #0 

0006 

0008 

000A 

4D05 

00A2* 

0000 

LD 

APT_EHTRY,  #0 

OOOC 

OOOE 

0010 

4D05 

000A' 

FFFF 

LD 

APT. BLOC KED.LIST,  ANIL 

0012 

0014 

4D08 

0000' 

CLR 

{*** 

APT. LOCK 

NOTE:  THE  FOLLOHING  CODE  IS  INCLUDED 
ONLY  FOR  SIHULATION  OF  A  MULTIPROCESSOR 
ENVIRONMENT.  THIS  IS  TO  INSURE  THAT  THE 
READY  LIST (S)  AND  VP  DATA  OF  THE  SIMULATED 
CPU(S)  ARE  PROPERLY  INITIALIZED.  IN  AN 
ACTUAL  MULTIPROCESSOR  ENVIRONMENT,  THIS 
BLOCK  OF  CODE  SHOULD  BE  REMOVED. 
*****************************  ************1 


0016 

2104 

LD 

R4,  *0 

0018 

0000 

DO 

00 1 A 

0BO4 

CP 

R4,  ANR_CPU*2 

001C 

0004 

IF  EQ 

1  ALL  LISTS  INITIALIZED! 

00  IE 

5E0E 

THEN 

EXIT 

0020 

0026* 

0022 

5E08 

0024 

0036' 

FI 

!  INITIALIZE  READY  LISTS  AS  EMPTY 

0026 

4D45 

LD 

APT. READY .LIST (R4J ,  ANIL 

0028 

0006* 

002A 

FFFF 

!  INITIALLY  MARK  ALL  LOGICAL  CPU'S 
AS  HAVING  1  VP.  THIS  IS  NECESSARY 
TO  INSURE  TC  ADVANCE  HILL  FUNCTION 
PROPERLY,  AS  IT  EXPECTS  EVERY  CPU 
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TO  HIVE  AT  LEAST  1  VP.  ! 


002C 

4045 

LO  APT.  VP.NR_VP(R4)  #  *1 

002E 

0010' 

0030 

0001 

0032 

A941 

INC  B4,  *2 

0034 

E8P2 

OD 

!  END  MULTIPROCESSOR  SIMULATION  CODE. 

************************«**«*****«*******; 

0036 

6P12 

LD  APT . VP. NR_ VP (Rl) ,  R2 

0038 

0010' 

003A 

6103 

LD  R3 ,  NEXT_VP 

003C 

00A0* 

003E 

6P13 

LD  APT. VP. FIRST (HI) ,  R3 

0040 

0014* 

!  RECOMPUTE  NEXT  VP  VALUE  POR  TC 
INITIALIZATION  OP  NEXT  LOGICAL 

CPU.  ! 

0042 

A125 

LD  R5 ,  R2 

0044 

1904 

MULT  RR4,  *2 

0046 

0002 

0048 

8153 

ADD  R3 ,  R5 

004A 

6P03 

LD  NEXT_VP,  R3 

004C 

00  AO* 

!  INITIALIZE  RUNNING  LIST  i 

004E 

6113 

LD  R3  t  APT .  VP.  PISST  (R 1) 

0050 

0014' 

DO 

0052 

0B02 

CP  R2,  *0 

0054 

0000 

0056 

5E0E 

IP  EQ  THEN  EXIT  PI 

0058 

005E' 

005A 

5E08 

005C 

006A ' 

005E 

4D35 

LD  APT.RUNNING_LIST  (R3)  ,  VIDLEJPROC 

0060 

0002’ 

0062 

DODD 

0064 

A931 

INC  R3#  *2 

0066 

AB20 

DEC  R2,  *1 

0068 

E8P4 

OD 

006A 

4D15 

LD  APT. READY_LIST (R1 )  ,  *NIL 

006C 

0006* 

C06E 

FPPF 

0070 

2101 

LD  R1 ,  *0 

0072 

0000 

!  ENTRY  ADDRESS  I 

0074 

7602 

LDA  R2 ,  VIRTUAL_PB£EMPT_HANDLER 

0076 

0054* 

0078 

5P00 

CALL  CREATE_INT_VEC 

007A 

0000* 

!R1 : VIRTUAL  INTERRUPT  * 

R2: INTERRUPT  HANDLER  ADDRESS! 

007C 

9E08 

RET 

007E 

END  TC  INIT 

267 


- 1 
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007E  CREATE  PROCESS  PEOCEDOBE 

» *******************41**41** 

*  CREATES  USEE  PROCESS  * 

*  DATABASES  AMD  APT  * 

*  ENT RIBS  * 

************************* 

*  PARAMETERS:  * 

*  B14:  ARGUMENT  PTE  * 
************** ***********1 


007B  030P 
0080  OOOA 

0082  6PPE 
0084  0000 

0086  7604 
0088  0000* 
008A  5P00 
008C  0000* 


008E  5P00 
0090  0000* 


0092  6101 
0094  00A2* 

0096  2102 
0098  0020 
009A  8112 

009C  6P02 
009E  00A2* 

OOAO  4D15 
00A2  0020* 
00A4  FFFP 
0CA6  6F10 
00A8  0022* 

OOAA  54 E 2 
00 AC  00 IE 
OOAE  5D12 
OOBO  0024* 

00B2  61E2 


ENTBT 

{NOTE:  THIS  PEOCEDOBE  IS  A  STOB  TO  ALLOH 
PROCESS  INITIALIZATION  FOB  IBIS 
DEMONSTRATION. ! 

!  ESTABLISH  STACK  FRAME  FOB  LOCAL 
FABIABLES.  1 

SOB  B 15*  iSIZEOF  CREATE 

1  STOBE  INPUT  ARGUMENT  POINTER  ! 

LO  CREATE. ABG_PTH (B15) ,  B14 

!  LOCK  APT  ! 

LDA  B4,  APT. LOCK 

CALL  K_LOCK 

1  BETOBNS  HHEN  APT  IS  LOCKED  ! 

(  CHEATS  MHO  ENTBT  FOR  PROCESS  i 
CALL  ALLOCAIEJfHU  1  BETOBNS; 

BO:  DBS  # i 

!  GET  NEXT  AVAILABLE  ENTBT  IN  APT  1 
LD  R1,  APT.ENTRI 

!  COMPOTE  APT  OFFSET  I 
LD  B 2*  ISIZEOF  AP.TABLS 

ADD  B2,  81 

!  SAVE  NEXT  AVAILABLE  APT  ENTBT  I 
LD  APT.BNTHT,  B2 

I  CHEATS  APT  ENTBT  FOB  PROCESS  I 
LD  APT. AP. NEXT_AP  (fil) ,  INIL 


LD  APT. AP*  DBB (B1)  *  BO 

!  GET  PROCESS  CLASS  ! 

LDL  BR2,  ASGJ.IST.SAC1  (B14) 

LDL  APT.  AP.  SAC  (R 1)  *  BB2 

i  GET  PROCESS  PBIORITT  1 
LD  R2,  ARG.UST.PRI1  (B14) 
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J 


00B4 

0022 

00B6 

6F12 

LO 

APT.  AP.  PRI  (R 1)  ,  R2 

00B8 

0028* 

!  GET 

LOGICAL  CPU  t  ! 

OOBA 

61E2 

LO 

R2,  ARG_LIST.CPU_ID(B14) 

OOBC 

00 1C 

OOBE 

6F12 

LD 

APT.  AP.  AFFINITY  (fll)  ,  R2 

OOCO 

002C* 

{THREAD  IN  LIST  AND  MAKE  READY 

00C2 

7623 

LOA 

R3,  APT  . READY.LIST  (R2) 

00C4 

0006* 

00C6 

7604 

LOA 

R4  ,  APT. AP. N£XT_AP 

00C8 

0020* 

OOCA 

7605 

LDA 

R5,  APT. AP. PRI 

OOCC 

0028* 

OOCE 

7606 

LOA 

R6 ,  APT. AP. STATE 

0000 

00  2A* 

0002 

2107 

LO 

R7 1  IREAOY 

0004 

0001 

0006 

AD21 

EX 

R 1 ,  R2 

!  SAVE  DBR  #  ! 

OOD8 

6FF0 

LD 

CREATE.  DBR.NOM  (R 15)  ,  RO 

OODA 

0002 

00  DC 

5F00 

CALL 

LIST.INSERT 

OODE 

0000* 

!R2:  OBJ  10 
B3:  LIST  BEAD  PTR 
R4:  NEXT  OBJ  PTR 
R5:  PRIORITY  PTR 
R6;  STATE  PTR 
R7 :  STATE! 

1  ON LOCK  APT  ! 


OOEO 

7604 

LDA 

R4 ,  APT. LOCK 

00E2 

0000' 

00E4 

5F00 

CALL 

K_UNLOCK 

00E6 

0000* 

{CREATE  OSER  STACK! 

I  RESTORE  ARGUMENT  POINTER  ! 

00E8 

61FE 

LO 

314,  CREATE. ARG_PTR(B15) 

OOEA 

0000 

00  EC 

61E3 

LO 

R3,  ARG_LIST.OSR.STK (R14) 

OOEE 

0024 

!  SAFE  LIMITS  ! 

OOFO 

6FF3 

LD 

CREATE. LIMITS (R1 5)  ,  S3 

00F2 

0004 

00F4 

5F00 

CALL 

REALLOCATE  (R3:  *  OF  BLOCKS 

OOF6 

0000* 

RETURNS: 

R2:  START  AOOR! 

{COMPOTE  &  SAVE  NSP! 

00F8 

A128 

LO 

R8,  R2 

!  ESTABLISH  INITIAL  SP  VALUE 

FOR 

USER  STACK.  ! 

OOFA 

0108 

ADO 

R8,  ASTK.OFFSET 
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OOPC 

00  FF 

00  FE 

6FF8 

LD 

CREATE.  N  S  P  (R15)  ,  R8 

0100 

0008 

!  RESTORE 

LIMITS  ! 

0102 

61F4 

LD 

R4, 

CREATE. LIMITS (R15) 

0104 

0004 

0106 

AB40 

DEC 

R4 

!  SEG  LIMITS! 

!  RESTORE 

DBR  ! 

0108 

61F0 

LD 

RO, 

CREATE.  DBR_NUM(R15) 

0  1 0A 

0002 

010C 

2101 

LD 

ai. 

#USER_STACK 

0 1 0E 

0003 

0110 

2103 

LD 

83, 

♦WRITE  {ATTRIBUTE! 

0112 

0000 

0114 

5F00 

CALL 

UPDATE  MHO  IMAGE 

0116 

0000* 

i BO:  OBR  * 

R1:  SEGMENT  « 

R2:  SEG  ADDRESS 
R3:  SEG  ATTRIBUTES 
R4 :  SEG  LIMITS! 

{CREATE  KERNEL  STACK! 

!  RESTORE  ARGUMENT  POINTER  ! 

0118  61PE  LD  R14,  CREATE. ARG_PTR (R1 5) 

011A  0000 

011C  61E3  LD  R3 ,  ARG  LIST.KER_STK (R14| 

01  IE  0026 

0120  5F00  CALL  MM  ALLOCATE  !R3:  I  OF  BLOCKS 
0122  0000* 

RETURNS 

R2:  START  ADDR! 


SHAKE  M MU  ENTRY! 

!  RESTORE  DBS  *  ! 


0124 

61F0 

LD 

RO,  CREATE. DBR_NUM (R15) 

0126 

0002 

0128 

2101 

LD 

R  1 ,  #KERNEL_STACK 

012A 

0001 

012C 

A134 

LD 

R4,  R3 

012E 

AB40 

DEC 

R4 

0130 

2103 

LD 

R 3,  tWRITE 

0132 

0000 

!  SAVE  START  ADDRESS  ! 

0134 

6PF2 

LD 

CREATE.  SEG.ADDR(R15J  ,  £ 

0136 

0006 

0138 

5F00 

CALL 

UPDATB.MMU .IMAGE 

013A 

0000* 

!R0:  DBR  * 

R1:  SEGMENT  * 

R2:  SEG  ADDRESS 
R3:  SEG  ATTRIBUTES 
R4:  SEG  LIMITS! 

! ESTABLISH  ARGUMENTS! 

!  RESTORE  ARGUMENT  POINTER  ! 
013C  6T?E  LD  R14v  CREATE. ARG_PTR(R15> 


013E  0000 


i  RESTORE  STACK  ADDRESS  ! 


0140 

61F1 

LD 

R  1 ,  CREATE. SEG  ADDR(R15) 

0142 

0006 

0144 

2103 

LD 

R3  0  #US  ER_FCH 

0146 

1800 

0148 

61E4 

LD 

84  ,  ARG_LIST .  IC  (R  1 4) 

0  14A 

00  1A 

!  RESTORE  INITIAL  NSP  i 

0  14C 

61F5 

LD 

85 ,  CREATE. N_S_P  (R15) 

014E 

0008 

0150 

7606 

LDA 

R6 ,  VIRT  PREEMPT  RETURN 

0152 

0076* 

0154 

030F 

SUB 

'15,  *8 

0156 

0008 

0156 

1CF9 

LDH 

3R15,  R 3,  *4 

015A 

0303 

!  LOAD  ARGUMENT  POINTER  FOR 

CREATE  STACK  CALL  t 

015C 

A1F0 

LD 

RO  ,  R 15 

015E 

93F1 

PUSH 

3R1S,  R 1 

0160 

A1E1 

LD 

Rlf  R 14 

!  LOAD  INITIAL  REGISTER  VALUES  TO 

BE 

PASSED  TO  USER  PROCESS 

AS 

INITIAL  PARAMETERS.  ! 

0162 

5C1 1 

LDH 

R2,  ARG_LIST .  REG  (R 1)  , 

*13 

0164 

020C 

0166 

0000 

0168 

97F1 

POP 

R1f  3R 1 5 

0  16A 

5F00 

CALL 

CREATE. STACK 

016C 

0000* 

!  RO:  ARGUMENT  PTR 

R1S  TOP  OP  STACK 
R2-H14:  INITIAL 

REG  STATESI 

INOTE 

:  THE  ABOVE  INITIAL  RE 

3  STATES 

REPRESENT  THE  INITIAL  PARAMETERS 

(VIZ 

.,  REGISTER  CONTENTS) 

THAT  A 

USER 

PROCESS  HILL  RECEIVE 

UPON 

INITIAL  EXECUTION.  I 

0 16E 

010F 

ADD 

R15f  #8  ! OVERLAY  PARAMETERS! 

0170 

0008 

!  ALLOCATE  KST  1 

0172 

2103 

LD 

83,  #KST_LIMIT 

0174 

0001 

0176 

5F00 

CALL 

HH.ALLOCATE  IR3:#  OF 

BLOCKS 

0178 

0000* 

RETURNS 

R  2:  START 

ADDR ! 

!  RESTORE  DBR  i 

0 17  A 

61F0 

LD 

RO  ,  CREATE. DBR.NUM (R15) 

017C 

0002 

t  SAVE  KST  ADDRESS  ! 

017E 

6FF2 

LD 

CREATE. SEG_ADDR(R15)  , 

R2 
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0180  0006 


I  MAKE  M  HO  ENTBI  FOB  KST  SBGI 


0182 

2101 

LD 

B1,  #KST_S EG 

0184 

0002 

0186 

2103 

LD 

B3 f  IWBITE  1 ATTBIB0TE1 

0188 

0000 

0 18A 

2104 

LD 

B4f  #KSTJ.IHII-1 

0  18C 

0000 

018E 

5F00 

CALL 

OPDATE_MHO_IMAGE 

0190 

0000* 

! BO:  DBB  * 

B1:  SEGMENT  * 

B2:  SEG  ADDBESS 

B3:  SEG  ATTBIBUTES 

B4:  SEG  LIMITS! 

!  BESTOBE  KST  AOOBESS  ! 

0192 

61F2 

LD 

B2,  CBE ATE. SEG_ADDB(B15) 

0194 

0006 

!  CBEATE  INITIAL  KST  STUB  ! 

0196 

5F00 

CALL 

CBEATE.KST  !B2:KST  ADDB1 

0198 

01  AO' 

!  BEHOVE  TEMPOBABI  VABIABLE 

STACK  FBAHE.  ! 

019A 

010F 

ADD 

BIS,  iSIZEOF  CBEATE 

019C 

OOOA 

019E 

9E08 

BET 

01  AO 

END  CBEATE.PBOCESS 
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OUO  CREATE_KST  PROCEDURE 

1  ************************ 

*  CREATES  KST  STOB  FOR  * 

*  PROCESS  MANAGEMENT  * 

*  DEMO.  INSERTS  ROOT  * 

*  ENTRY  IN  KST.  NOT  * 

*  INTENDED  TO  BE  PINAL  * 

*  PRODUCT.  * 

************************ 

*  PARAMETERS:  * 

*  R2:  KST  ADDRESS  * 

************************] 

ENTRY 

{NOTE:  THIS  PROCEDURE  IS  A  STUB  USED 
FOR  INITIALIZATION  IN  THIS  IMPLEMENTATION 
ONLY.  THE  ACTUAL  INITIALIZATION  CODE 
FOR  THE  KST  HILL  RESIDE  AT  THE  SEGMENT 
MANAGER  LEVEL  ONCE  IMPLEMENTATION  OF 
SYSTEM  INITIALIZATION  IS  EFFECTED.  ! 


!  CREATE  ROOT  ENTRY  IN  KST  ! 


0  1  AO 

1406 

LDL 

RR6,  #-1  {ROOT  HANDLE 

01A2 

FFFF 

01A4 

FFFF 

01A6 

5D26 

LDL 

KST.  MM_HAND£*?  (R2)  ,  RR6 

01A8 

0000 

ISET 

ROOT  ENTRY  t  IN  G_AST  { 

0  1 AA 

4D25 

LD 

KST.  MH_HANDLE[  2]7R2)  , 

01  AC 

0004 

01AE 

0000 

!  SET  ROOT  CLASSIFICATION  ! 

0 1B0 

1406 

LDL 

RR6,  #SYSTEM_LOH 

0  1B2 

0000 

01B4 

0000 

01B6 

5D26 

LDL 

KST. CLASS (R2)  ,  RR6 

01B8 

OOOA 

ISET 

MENTOR  SEG  t{ 

01  BA 

4C25 

LDB 

KST.  M_SEG_NO  (R2)  ,  *0 

0  1BC 

000E 

0 1BE 

0000 

UNITIALIZE  FREE  KST  ENTRIES 

FOR 

DEMO.  NOT  FULL  KST{ 

01C0 

2101 

LD 

HI,  #10 

01C2 

OOOA 

DO 

0 1C4 

0B01 

CP 

to 

% 

O 

01C6 

0000 

01C8 

5E0E 

IF 

EQ  THEN  EXIT  FI 

0  1CA 

01  DO’ 

01CC 

5E08 

0  ICE 

01DE* 

0  IDO 

0102 

ADD 

R2 ,  ISIZEOF  KST.REC 

01D2 

0010 

i 


I 
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0  1D4 

4C25 

LDB 

KST.  H_SEG_NO  (H2)  ,  #*FP 

01D6 

OOOE 

01D8 

PPPP 

01  DA 

AB10 

DEC 

B 1 

0 1DC 

E8P3 

OD 

0 1 DE 

9E08 

BET 

0  ISO 

END  CREATE_KST 
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0 1 EO  TC_ADVANCE  PROCEDURE 

•  ******************************** 

*  EVENICOUNT  IS  ADVANCED  BT  * 

*  INVOCATION  OF  MM  ADVANCE.  * 

*  PROCESSES  THAT  ARE  AWAITING  * 

*  THIS  EVENT  OCCURRENCE  ARE  * 

*  REMOVED  FROM  THE  BLOCKED  LIST* 

*  AND  HADE  READY.  THE  RBADI  * 

*  LISTS  ARE  THEN  CHECKED  TO  * 

*  INSURE  PROPER  SHEDULING  IS  * 

*  EFFECTED.  IP  NECESSARY  VIR-  * 

*  TUAL  PREEMPTS  ARE  SENT  TO  ALL* 

*  THOSE  VP'S  BOUND  TO  LONER  * 

*  PRIORITY  PROCESSES.  * 

******************************** 

*  PARAMETERS:  * 

*  R1 :  HANDLE  POINTER  * 

*  R2:  INSTANCE  (EVENT  *)  * 

******************************** 

*  RETURNS:  * 

*  R 0:  SUCCESS  CODE  * 

********************************] 

ENT  RY 

1  ESTABLISH  TEMPORARY  VARIABLE 
STACK  FRAME.  ! 


0 1  EO 

030F 

SUB 

R 15,  iSIZEOF  TEMP 

01E2 

0012 

!  SAVE  INPUT  ARGUMENTS  ! 

01E4 

6FF1 

LD 

TEMP.  HANDLE_PTfi  (B15) 

0  1 E6 

GOOO 

01E8 

6FF2 

LD 

TEMP . EVENT_NR  (R15) , 

0 1 EA 

0002 

!  LOCK  APT  ! 

0 1EC 

7604 

LDA 

R4 ,  APT. LOCK 

0  1EE 

0000* 

0 1F0 

5F00 

CALL 

K_LOCK 

0  1F2 

0000* 

!  RETURNS  WHEN  APT  IS  LOCKED  ! 

!  ANNOUNCE  EVENT  OCCURRENCE  BY 

INCREMENTING  EVENICOUNT  IN  G  AST! 
01F4  5F00  CALL  MM  ADVANCE  1 R1 :H ANDLE  PTR 
0 1F6  0000* 

R2 :I NSTANCE 
RETURNS: 

RO  :S  tJCCESS  CODE 
RB2: EVENICOUNT! 

01F8  0B00  CP  RO,  ^SUCCEEDED 

0 1FA  0002 

0 1FC  5E0E  IF  EQ  THEN 

01FE  0372' 

!  SAVE  BVENTCOUNT  ! 

0  200  5DF2  LDL  TEMP. EVENT_V AL  (R15) ,  BR2 

0202  0004 


0204  6 1F0 
0206  0002 

0208  61P1 
020A  0000 


020C 
0202 
0210 
0212 
0214 
0216 
0218 
021 A 


5414 

0000 

50F4 

000C 

6114 

0004 

6FP4 

0010 


t  RESTORE  INSTANCE  ! 

LD  HO,  TEHP .E VENT_NR (B15) 

t  RESTORE  HANDLE  POINTEB  ! 

LD  B 1 #  TEMP.HANDLE_PTB (B1 5) 

!  SAVE  HANDLE  ! 

LDL  RR4,  HANDLE_VAL. HIGH (B1) 

LDL  TEHP.HANDLE.HIGH  (B15) ,  BB4 

LD  B4  ,  HANDLE.VAL.LOH  (B1| 

LD  TEHP.HANDLS_LOH(B15) ,  B4 

!  A8AKEN  ALL  PB0CESS2S  A8AIIING 
THIS  EVENT  OCCOBBENCE  ! 

!  GET  FIRST  BLOCKED  P30CESS  ! 


021C 

6101 

LD 

B  1 

02  IE 

000A* 

0220 

7606 

LD  A 

B6 

0222 

000A* 

HAKE_UP: 

DO 

!  DETEHHINE  IF  AT  END  OF  BLOCKED  LIST  I 


0224 

0B01 

CP 

R  1  #  »NIL 

0226 

FFFF 

IF  EQ 

!  NO  NOBE  BLOCKED  PBOCBSSE S  f 

0228 

5E0E 

THEN 

EXIT  EBON  HAKE.OP 

022A 

0230' 

022C 

5E08 

022E 

02B4* 

FI 

!  SAVE 

1  NEXT  ITEH  IN  LIST  ! 

0230 

6117 

LD 

R7,  APT.AP. NBXT_AP(B1) 

0232 

0020* 

!  DETERMINE  IF  PROCESS  IS  ASSOCIATED 

8ITH 

CURRENT  HANDLE  1 

0234 

54P4 

LDL 

RR4,  TEHP.  HANDL£_HIGH  (R  15) 

0236 

OOOC 

0238 

5014 

CPL 

RR4 ,  APT. AP. HANDLE (B1) 

023A 

0030' 

IF  EQ 

{HIGH  HANDLE  VALUE  HATCHES! 

023C 

5E0E 

THEN 

023E 

02A2* 

0240 

61F4 

LD 

R4,  TEHP. HANDLE _LOB (B15) 

0242 

0010 

0244 

4B14 

CP 

R4,  APT.AP.  HANDLE[2](B1) 

0246 

0034* 

IF  EQ 

!  HANDLE*  S  HATCH  ! 

0248 

5E0E 

THEN 

!  CHECK  FOB  INSTANCE  HATCH  ! 

024A 

02  9C* 

024C 

6 1FO 

LD 

RO,  TEHP. EVENT_NB (&15) 

024E 

0002 
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0250  4B10  CP  BO,  APT .  AP.  INSTANCE  (B 1) 

0252  0036* 

IF  2Q  !  INSTANCE  HATCHES  1 
0254  5E0E  THEN  ! OETEBHIN E  IF  THIS  IS  THE 

0256  0296' 

OCCUBBENCE  THE  PBOCESS 
WAITING  FOB  ! 


0258 

54F2 

LDL 

BB2, 

TEHP.EVENT.VAL  (B  15) 

025A 
0  25C 

0004 

5012 

CPL 

BB2, 

APT. AP. VALUE (fil) 

0 25E  0038* 

IF  GE  ! AWAITED  EVENT  HAS  OCCDBBBD! 
0260  5E0 1  THEN  !  AWAKEN  PBOCESS  1 

0262  0290* 

1  BEHOVE  FBOB  BLOCKED  LIST  1 
0264  2F67  LD  8B6,  B7 

!  SAVE  LOCAL  VABIABLES  ! 

0266  91F6  POSHL  8815,  BB6 

! SET  LIST  THBEADING  ABGUHENTS! 


0268 

6112 

LD  B2, 

APT.  AP.  AFFINITY  (Bl) 

026A 

002C« 

0  26C 

7623 

LDA  B3, 

APT  .BEADY ..LIST (B2) 

026E 

0006' 

0270 

7604 

LDA  B4, 

APT . AP. NEXT_AP 

0272 

0020' 

0274 

7605 

LDA  B5, 

APT. AP. PBI 

0276 

0028* 

0278 

7606 

LDA  B6, 

APT. A P. STATE 

027A 

002A' 

027C 

2107 

LD  R7, 

♦  BEADY 

027E 

0001 

0280 

A112 

LD  B2, 

Bl 

0282 

5FOO 

CALL  LIST.INSEHT 

0284 

0000* 

!R2:  OBJ 

ID 

B3:  LIST  HEAD  PTB 

B4:  NEXT  OBJ  PTB 

R5:  PRIORITY  PTB 

B6:  STATE  PTB 

K7:  STATE  VALUE  ! 

!  BESTOBE  LOCAL  VABIABLES  ! 
0286  95F6  POPL  BB6 ,  SB  15 

0288  210B  LD  B11,  #B SHOVED 

028A  ABCD 

028C  5E08  ELSE  I PBOCESS  STILL  BLOCKED! 

028E  0292* 

0290  8DB8  CLB  B11 

FI  !  END  VALUE  CHECK  ! 

0292  5E08  ELSE  {PROCESS  STILL  BLOCKED! 

0294  0298' 

0296  8DB8  CLB  R11 

FI  !  END  INSTANCE  CHECK  ! 

0298  5E08  ELSE  {PROCESS  STILL  BLOCKED! 

029A  Q29E' 
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029C  8DB8 


CLR  811 

PI  !  END  HANDLE  CHECK  ! 


029E 

5E08 

ELSE  ! PBOCESS  STILL  BLOCKED! 

02A0 

02A4  • 

02A2 

8DB8 

CL 8  811 

PI  !  END  HIGH  HANDLE  CHECK  ! 

!  BESET  AP  POINTER  REGISTERS  ! 

02A4 

OBOB 

CP  R11,  •BEHOVED 

02A6 

ABCD 

IF  NE  !  PBOCESS  IS  STILL  BLOCKED  ! 

02A8 

5E06 

THEN 

02AA 

02B0* 

02  AC 

7616 

LDA  86,  APT. AP*  NEXT.AP (81) 

02AE 

0020* 

PI 

02B0 

A17 1 

LD  81,  87 

02B2 

E8B8 

OD 

!  DETERMINE  IP  ANY  VIRTUAL  PREEMPT 
INTERRUPTS  ARE  REQUIRED  I 

0284 

8D28 

CL  8  R2 

PREEMPT  CHECK: 

DO 

02B6 

0B02 

CP  82,  #NR_CPU  *  2 

02B8 

0004 

0  2BA 

5E0E 

IP  EQ  ! ALL  READY  LISTS  CHECKED!  THEN 

02BC 

02C2* 

02BE 

5E08 

EXIT  FROH  PREBMPT.CHECK 

02C0 

0366* 

FI 

!  CREATE  PREEMPT  VECTOR  POR  VP* S  ! 

02C2 

8D18 

CLR  R1 

DO  ! FOR  R 1= 1  TO  NR  VP'S! 

02C4 

A910 

INC  R1 

02C6 

4B21 

CP  R 1 ,  APT. VP.NR.VP  (R2) 

02C8 

0010* 

IP  GT  !  PREEMPT  VECTOR  COMPLETED  ! 

02CA 

5E02 

THEN  EXIT 

02CC 

02D2' 

02CE 

5E08 

02D0 

02D8* 

PI 

0202 

0DP9 

PUSH  9R 15,  tTRUE 

02D4 

0001 

0  2D6 

E8P6 

OD 

!  #  TO  PREEMPT  ! 

02D8 

8D38 

CLR  R3 

02DA 

6124 

LD  R4,  APT.  VP.  NB.VP  (R2J 

0  2  DC 

0010' 

!  #  OP  VP'S  1 

!  GET  FIRST  READY  PROCESS  ! 

02DE 

6121 

LD  R1,  APT. READY .LIST (R2) 

02E0 

0006* 

CHECK  RDY.LIST: 
DO 


!  SEE 

IP  RE1DY  LIST  IS  EMPTY  ! 

02E2 

0B01 

CP 

Rif  VEIL 

0  2E4 

PPFP 

IP  EQ 

1LIST  IS  EMPTY! 

0  2E6 

5E0E 

THEE 

EXIT  FROM  CH ECK_RD Y_LIST 

02E8 

02EE* 

02  El 

5E08 

02  EC 

0324* 

PI 

02EE 

4011 

CP 

APT.1P.ST1TE  (R 1)  ,  f B0EHIMG 

02P0 

0021* 

02P2 

0000 

IP  EQ 

! PROCESS  IS  R0EEIEG! 

0  2P4 

5E0E 

THEE 

! DOE ' T  PREEMPT  IT! 

02P6 

030C* 

02P8 

6115 

LD 

R5,  1PT.  IP • VP_ID  (R 1) 

02P1 

002E* 

! COMPUTE  L0C1TI0E  IE  PREEMPT  VECTOR! 

02PC 

4325 

SOB 

85,  APT.  VP. FIRST  (R2) 

02PE 

0014* 

0300 

74P6 

LD1 

R6,  R15(R5) 

0302 

0500 

0304 

0065 

LD 

8R6,  #PALSE 

0306 

0000 

0308 

5E08 

ELSE 

!  PREEMPT  IT  ! 

0301 

030E* 

030C 

1930 

IEC 

R3 

PI 

0  30E 

1B40 

DEC 

R4 

0310 

0B04 

CP 

R4,  10 

0312 

0000 

IP  EQ 

! ILL  VP*S  VERIFIED! 

0314 

5E0E 

THEE 

0316 

03 1C* 

0318 

5E08 

EXIT  PROS  CHECK  RDI  LIST 

0311 

0324* 

PI 

!  GET 

EEXT  IP  IE  RE1DY  LIST  ! 

03 1C 

6110 

LD 

RO,  APT.  AP.EEXT.IP(RI) 

0  3  IE 

0020* 

0320 

1101 

LD 

81,  RO 

0322 

E80P 

OD  ! END  CHECK_RDY_LIST! 

!  SET 

EECESS1RY  PREEMPTS  ! 

0324 

6124 

LD 

R4,  APT. VP. ER_VP (R2) 

0326 

0010* 

0328 

6121 

LD 

R1,  APT. VP. FIRST (R2) 

0321 

• 

O 

o 

SEED  PREEHPT: 

DO 

032C 

97P0 

POP 

RO,  8R15 

!  CHECK  TEHPL1TE  ! 

032E 

0B00 

CP 

RO,  ITROE 

0330 

0001 

IP  EQ 

! CAE  BE  PREEMPTED! 
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THEM 


0332  5E0E 
0334  0350* 
0336  0B03 
0338  0000 

033A  5E02 
033C  0350* 

033B  93P1 
0340  91F2 
0342  93P4 
0344  5P00 
0346  0000* 


0348  97P4 
034A  95P2 
034C  97P1 
034E  A830 


0350  A911 
0352  AB40 
0354  0B04 
0356  0000 

0358  5E0E 
035A  0360* 
035C  5E08 
035E  0362* 

0360  E8E5 

0362  A921 
0364  E8A8 

0366  7604 
0368  0000' 
036 A  5P00 
036C  0000* 

036E  2100 
0370  0002 


0372  010P 
0374  0012 
0376  9E08 
0378 


CP  R3,  #0 

IF  GT  ! PREEMPTS  REQUIRED! 
THEM  I  PREEMPT  IT! 


I  SATE 

ARGUMENTS! 

PUSH 

8815,  R1 

PUSHL 

8815,  RR2 

PUSH 

8815 ,  R4 

CALL 

SET^PREEMPT 

!  R1 : 

VP  ID! 

!  RESTORE 

ARGUMENTS  ! 

POP 

R4, 

8R1S 

POPL 

R82, 

8R1 5 

POP 

R1, 

8R1S 

DEC 

R3 

PI 

PI 

INC 

81, 

#2 

DEC 

R4 

CP 

84, 

#0 

IP  EQ  ISTACK  RESTORED ! 
THEM 


EXIT 


PI 

OD  ! END  SEND..  PREEMPT! 

1  CHECK  NEXT"’beADY  LIST  I 
IMC  R2,  #2 
OD  ! END  PREEMPT  CHECK! 

!  UNLOCK  APT  I 
LDA  R4r  APT. LOCK 

CALL  KJJHLOCK 

!  RESTORE  SUCCESS  CODE  ! 

LD  RO,  iSUCCEEDED 

PI 

!  RESTORE  STACK  ! 

ADD  R15,  ISIZEOF  TEMP 

RET 

END  TC  ADVANCE 
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1  ******************************** 

*  CHECKS  USER  SPECIFIED  VALUE  * 

*  AGAINST  CURRENT  EVENTCOUNT  * 

*  VALUE.  IF  USER  VALUE  IS  LESS  * 

*  THAN  OR  EQUAL  EVENTCOUNT  THEN* 

*  CONTROL  IS  RETURNED  TO  USER.  * 

*  ELSE  USER  IS  BLOCKED  UNTIL  * 

*  EVENT  OCCURRENCE.  * 

******************************** 

*  PARAMETERS:  * 

*  R1 :  HANDLE  POINTER  * 

*  R2 :  INSTANCE  (EVENT  *)  * 

*  RR4 :  SPECIFIED  VALUE  * 

******************************** 

*  RETURNS:  * 

*  RO:  SUCCESS  CODE  * 

********************************  1 


k  : 


ENTRY 

!  ESTABLISH  STACK  FRAME  FOR 
TEMPORARY  VARIABLES.  I 


0378 

030F 

SUB 

R15,  tSIZEOF  TEMP 

037A 

0012 

* 

'i 

!  SAVE  INPUT  PARAMETERS  ! 

0  37C 

6FF 1 

L  D 

TEMP. HANDLE  PTR(fi15),  HI  1 

037E 

0000 

~  t 

! 

0380 

6FF2 

LD 

T EMP . EVENT_NR (HI 5)  ,  R2 

0382 

0002 

0384 

5DF4 

LDL 

TEMP. EVENT  VAL(RIS),  RR4 

0386 

0004 

1 

1 

!  LOCK  APT  I  i 

0388 

7604 

LD  A 

R4  ,  APT. LOCK  j 

0  38A 

0000* 

I 

038C 

5F00 

CALL 

K_LOCK  j 

0  38E 

0000* 

!  RETURNS  HHEN  APT  IS  LOCKED  ! 

!  GET 

CURRENT  EVENTCOUNT  1 

0390 

5F00 

CALL 

HM_READ_EVBNTCOUNT 

0392 

0000* 

t  R 1 : HANDLE  POINTER 

R2: INSTANCE 

RETURNS: 

RO:SUCCESS_CODE 

RR4 :  EVENTCOUNT 1 

0394 

0B00 

CP 

RO,  iSUCCEEDED 

0396 

0002 

0398 

5E0E 

IF  EQ 

THEN 

039A 

0440* 

!  DETERMINE  IF  REQUESTED  EVENT 
HAS  OCCURRED  ! 

LDL  RR6,  TEMP. EVENT  VAL(R15) 


039C  54F6 
039B  0004 
03A0  9046 


CPL  RR6,  RR4 
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03A2  5E02 
03A4  0440* 

03A6  5F00 
03A8  0000* 


03AA  6FP1 
0  3 AC  0008 
03  AE  6FP3 
03B0  000A 
0382  6118 
03B4  0002* 

03B6  61P2 
0  338  0002 
03BA  61P1 
03BC  0000 

03BE  5414 
03C0  0000 
03C2  5D84 
03C4  0030* 
03C6  6114 
03C8  0004 
0  3CA  6P84 
03CC  0034* 
03CE  6FQ2 
03D0  0036' 
03D2  54P6 
03D4  0004 
03D6  5D86 
0308  0038* 

03DA  6181 
03DC  002C' 
03DE  6112 
03E0  0006* 


03E2  8882 

03E4  5E0E 
03B6  03P4* 
03E8  6183 
03EA  0020* 
C3EC  6P13 
03EE  0006* 
03P0  5S08 
03P2  040E* 

03F4  6123 


IP  GT  ! EVENT  HAS  NOT  OCCOBfiEDJ 
THEN  ! BLOCK  PSOCESS! 

I  IDENTIFY  PROCESS  ! 

CALL  BONNING.VP  1BET0BNS: 

B1:¥P  10 
B3:CP0  #! 

!  SAVE  RETORN  VARIABLES  ! 

LD  TEMP. ID^VP  (R 15) ,  R1 

LD  TEMP.  CPU_NOM  (B 15)  ,  R3 

LD  88,  APT. RUHNING_LIST (R1) 

!  RESTORE  REMAINING  ARGUMENTS  ! 

LD  R2,  TEHP.EVENT_NR(R15) 

LD  81 ,  TEMP. HAN DLE_PTR (R15) 

!  SAVE  EVENT  DATA  ! 

LDL  RR4,  HANDLE_VAL.  HIGH  (R 1) 

LDL  APT. AP. HANDLE (B8) ,  BB4 

LD  R4,  H  A  KDLE_V AL . LON ( B 1 ) 

LD  APT.  AP. HANDLER  2  ]  (BB)  ,  B4 

LD  APT. AP. INSTANCE  (R8) ,  R2 

LDL  RB6,  TEMP.  EV ENT_VAL  (B 1 5) 

LDL  APT. AP. VALUE  (B8) ,  BB6 

!  REMOVE  PROCESS  PROM  READ!  LIST  ! 
LD  R1,  APT. AP. AFFINITY (88) 

LD  R2,  APT. BEAD Y_LIST (B1) 

!  SEE  IF  PROCESS  IS  FIRST 
ENTRY  IN  BEADY  LIST  ! 

CP  R2 ,  R8 

IF  EQ  I INSEBT  NEB  READY  LIST  HEAD! 
THEN 

LD  83,  APT. AP.HEXT_AP (B3) 

LD  APT.READY_LIST(R1)  ,  B3 

ELSE  1DELETE  FROM  LIST  BODY! 

DO 

LD  R3,  APT. AP. NEKT.AP (R2) 
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0  3F6 

0020* 

03F8 

8B83 

CP 

R3 ,  R8 

IP  EQ 

! POUND  ITEM  IN  LIST! 

03FA 

5E0E 

THEN 

0  3PC 

040A* 

03PE 

6183 

LD 

R3,  APT . AP . NEXT_AP  (R8) 

0400 

0020* 

0402 

6P23 

LD 

APT. AP. NEXT_AP (R2) ,  R3 

0404 

0020* 

0406 

5S08 

EXIT 

0408 

040E* 

PI 

04  OA 

A132 

LD 

R2 ,  R3 

040C 

E8P3 

OD 

PI 

iTHREAD  PROCESS  IN  BLOCKED  LIST! 

040E 

A182 

LD  R2 , 

R8 

0410 

7603 

LDA  R3 , 

APT. BLOC KED_ LIST 

0412 

000A' 

0414 

7604 

LDA  R4 , 

APT.  AP.NEXT_.AP 

0416 

0020* 

0418 

7605 

LDA  R5, 

APT. AP.PRI 

04  1 A 

0028' 

04  1C 

7606 

LDA  R6, 

APT. AP. STATE 

04  1 E 

002  A* 

0420 

2107 

LD  R7 , 

* BLOCKED 

0422 

0002 

0424 

5P00 

CALL  LIST  INSERT  !R2:OBJ  ID 

0426 

0000* 

H3 : LIST  HEAD  PTE 
E4:NEXT  OBJ  PTE 
E5 : PRIORITY  PTE 
B6:STATE  PTE 
R7 : STATE  ! 

!  SET  CURRENT  7P  ID  ! 


0428 

61P1 

LD 

R1,  TEBP.ID_.7P  (R15) 

042A 

0008 

042C 

61F3 

LD 

R3,  TEHP.CPQ_NUM  (R15) 

042E 

000A 

!  SCHEDOLE  FIRST  READ!  PROCESS 

0430 

5FOO 

CALL 

TC_GETHOHK  iBl:7P_ID 

0432 

0000* 

B3:CPU  *1 

i  UNLOCK  APT  ! 

0434 

7604 

LDA 

R4 ,  APT. LOCK 

0436 

0000* 

0438 

5P00 

CALL 

K_UNLOCK 

043A 

0000* 

!  RESTORE  SUCCESS  CODE  ! 

043C 

2100 

LD 

RO  f  tSUCCEEDED 

043E 

0002 

PI 

PI 

!  RESTORE  STACK  ! 


ADD  ai5,  tSIZEOF  TEMP 


0440  010F 
0442  0012 
0444  9E08  SET 
0446  END  TC_A«AIT 
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3 


0446 


PROCESS_CLASS  PBOCEDUBE 

] **************************** 

*  BEADS  SECURITY  ACCESS  * 

*  CLASS  OF  CURRENT  PBOCESS  * 

*  IN  APT.  CALLED  BY  SEG  * 

*  MGR  AND  E7ENT  MGR  * 

**************************** 

*  LOCAL  7 ABIABLES :  * 

*  Bis  7P  ID  * 

*  B5:  PBOCESS  ID  * 

**************************** 

*  RETURNS  S  * 

*  HB2:  PROCESS  SAC  * 

****************************  I 


ENTRY 

0446 

7604 

LDA 

R4f APT. LOCK 

0448 

0000* 

044A 

5F00 

CALL 

K.LOCK  !  B4  S-.APT .  LOCK! 

044C 

0000* 

044E 

5F00 

CALL 

RONNING_VP  ! RETURNS : 

0450 

0000* 

B  1: 7P  ID 

B3: CPU  #! 

0452 

6115 

LD 

R  5 , APT . RUN NING_LI ST (B 1 ) 

0454 

0002* 

0456 

5452 

LDL 

B R2,  APT .  AP .  SAC  (B5) 

0458 

0024* 

!  UNLOCK  APT  ! 

045A 

7604 

LDA 

R 4 ,  APT. LOCK 

045C 

0000* 

045E 

5F00 

CALL 

K..UNLOCK 

0460 

0000* 

0462 

9E08 

BET 

0464 

END  PROC ESS_CL ASS 
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0464  SET  DBS  NUMBER  PfiOCEOUBE 

********************************** 

*  OBTAINS  DBS  NUMBER  FROM  APT  * 

*  FOR  THE  CURBENT  PROCESS.  * 

*  CALLED  BT  SEGMENT  MANAGER  * 


*  LOCAL  VARIABLES :  * 

*  Bis  VP  ID  * 

*  B5:  PROCESS  ID  * 

********************************* 

*  RETURNS:  * 

*  Hi :  DBR  NUMBER  * 

********************************* i 

ENTRY 

! NOTE:  DBR  *  IS  ONLY  VALID  HHILE  PROCESS 
IS  LOADED.  THIS  IS  NO  PROBLEM  IN  SASS 
AS  ALL  PROCESSES  REMAIN  LOADED.  IN  A 
MORE  GENERAL  CASE,  THE  DBR  *  COULD  ONLY 
BE  ASSUMED  CORRECT  WHILE  THE  APT  IS  LOCKED! 


0464 

0466 

7604 

0000* 

LDA 

R4, APT. LOCK 

0468 
046  A 

5F00 

0000* 

CALL 

K_LOCK  !R4: -.APT. LOCK! 

046C 

046E 

5F00 

0000* 

CALL 

RUNNING_VP  I  RETURNS: 

R1: VPJLD 
R3: CPU  #! 

0470 

0472 

6115 

0002' 

LD 

R5, APT. RUNNING  LIST(RI) 

0474 

0476 

6151 

0022* 

LD  R1,APT. AP.DBfi(R5) 

1  UNLOCK  APT  i 

0478 

047A 

7604 

0000* 

LDA 

R4 ,  APT. LOCK 

047C 

047E 

5FOO 

0000* 

CALL 

K_UNL0CK 

0480 

9E08 

RET 

0482 

END  GET_DBR_ NU MBER 

END  TC 
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Appendix  C 

DISTRIBUTED  MEMORY  MANAGER  LISTINGS 


Z8000ASM  2.02 

LOC  OBJ  CODE  STMT  SOURCE  STATEMENT 

SLISTON  STTY 
DIST.MM  MODULE 

CONSTANT 


CREATE  CODE 


50 


DELETE  CODE 
ACTIVATE_CODE 
DEACTIVATE  CODE 
SNAP  IN  CODE 
SBAP_OUT  CODE 
NR  CPU 
NR_KST_ENTRY 
MAX  SEG  SIZE 
MAX  DBR  NO 
KST.SBG  NO 
NR  OF  KSEGS 
BLOCK  SIZE 
MEM_AVAIL 
G  AST  LIMIT 
INSTANCE1 
INSTANCE2 
INVALID  INSTANCE 
SUCCEEDED 


51 

52 

53 

54 

55 
2 

54 

128 

4 

2 

10 

8 

XFOO 

10 

1 

2 

95 

2 


TYPE 

H  ARRAY 

COH_MSG 

addIess 

G_AST_RBC 
fuNIQUE  ID 
3LOBAL  ADDR 
P  L  ASTE  NO 
FLAG 
PAR_ASTE 
NR_ACTIVE 
NO  ACT  DEP 
SIZE1 


ARRAY  £3  WORD] 
ARRAY  [16  BYTE] 
BORD 

RECORD 

LONG 

ADDRESS 

BORD 

BORD 

BORD 

BORD 

BYTE 

BYTE 
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PG_TBL  ADDRESS 

ALIAS  TBL  ADDRESS 

S  EQOENCER  LONG 

B7ENT1  LONG 

EYENT2  LONG 

] 

MM.YP.ID  HORD 

SEG.ARRAY  ARRAY  [ MAX.SEG.SIZE  BYTE] 

SSECTION  D.MM.DAT A 

GLOBAL 

0000  MM.CPO.TBL  ARRAY  [ NR.CPU  MM.YP.ID] 

{SECTION  A YAIL.MEM 

INTERNAL 

!  NOTE:  MEM.POOL  IS  LOCATED  IN 
CPU  LOCAL  NEHORY.  ! 

0000  MEM.POOL  ARRAY  [MEM.AYAIL  BYTE] 

GLOBAL 

!  NOTE:  NEXT.BLOCK  IS  USED  IN  THE  Nil  .ALLOCATE 
STUB  AS  AN  OFFSET  POINTER  INTO  THE  BLOCK 
OF  ALLOCATABLE  MEMORY.  IT  IS  INITIALIZED 
IN  BOOTSTRAP  LOADER,  t 

0F00  NEXT  BLOCK  MOBD 

SSECTION  MSG  FRAME  DCL 
INTERNAL 

! NOTE:  THESE  RECORDS  ARE  "OYERLAYS*  OR  "FRAMES"  USED 
TO  DEFINE  MESSAGE  FORMATS.  NO  MEMORY  IS  ALLOCATED  ! 

SABS  0 

0000  CREATE  MSG  RECORD  [  CR  CODE  NORD 

CE.HM  HANDLE  H  ARRAY 
CE.ENTRY.NO  SHORT.INTEGEH 
CE  FILL  BYTE 

CE  SIZE  HORD 

CB.CLASS  LONG] 

SABS  0 

0000  DELETE  MSG  RECORD  [ DE.CODE  HORD 

DE.MM.HANDLE  H  ARRAY 
DE  ENTRY  NO  SHORT  INTEGER 
DE.FILL  ARBAY[  7  BITE]] 

SABS  0 

0000  ACTIYATB  MSG  RECORD  [  ACT.CODE  HORD 

A.DBR.NO  HORD 

A.MM.HANDLE  H  ARRAY 
A  ENTRY  NO  SHORT  INTEGER 
A  SEGMENT  NO  SHORT  INTEGER 
A  FILL  LONG] 
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0000 


0000 


0000 


0000 


0000 


0000 


SABS  0 

DEACTIVATE  HSG 


SABS  0 
SWAP  IN  MSG 


SABS  0 

SWAP  OOT  HSG 


SABS  0 
SET  SOC  CODE 


SABS  0 

a  ACTIVATE  ABG 


BECOBDf  DEACT.CODE 

NOBD 

D  DBS  NO 

NOBD 

D.HB.HANDLE 

H  ABBA  I 

D_FILL 

ABB  AI[  3 

NOBD]] 

RECOBD  [S_IN_CODE 

NOBD 

SI  h!  HANDLE 

H  AfifiAr 

SIDBB  NO 

NOBD 

SI  ACCESS  AUTH  BITE 

SI  FILL1 

BITE 

SI_FILL 

ABBAI[  2 

NOBD]] 

BECOBD  [ S_OOT_CODE 

NOBD 

SO  DBB  NO 

NOBD 

SO_HH_HANDLE 

a  ABBA! 

SO_FILL 

ABB  AI[  3 

NOBD]] 

BECOBD^ SUC  CODS 

BITE 

SC~FILL 

ABBAI[  15 

bite]; 

BECOBD  [B  SUC  CODE 

BITE 

B  FILL 

BITE 

B_HH_HANDLE 

H_ABBAI 

B  CLASS 

LONG 

B  SIZE 

NOBD 

B  FILL1 

NOBD  j 

SABS  0 

HM_HANDLE  BECOBD 

[ ID  LONG 

ENTBT  NO  WORD 

] 

EXTEBNAL 

G  AST  LOCK 


NOBD 


G_AST  AHBAr[G_AST_LIflir  G_ASI_BBC ] 


K_LOCK 

K_UNLOCK 

GET_CPU_NO 

SIGNAL 

BAIT 


PBOCEDUBE 

PBOCEDUBE 

PBOCEDUBE 

PBOCEDUBE 

PBOCEDUBE 
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GLOBAL 

{SECTION  D.MM.PROC 

0000  MM.CREAIE.ENTRY  PBOCEOUSE 

I  ******************** ************* 

*  I  NT ERF  ACE  BETWEEN  SBG  MGR  * 

*  (CREATE  SEG  PROCEDURE)  AND  * 

*  H HGR  PROCESS  (CREATE  ENTRY  * 

*  PROCEDURE) .  ARRANGES  AND  * 

*  PERFOBBS  IPC.  * 


*  REGISTER  USE:  * 

*  PARAHETSRS  * 

*  RO : SOCCESS.CODE  (RET)  * 

*  BltHPTR  (INPOT)  * 

*  R2:  ENTRI.NO  (INPUT)  * 

*  R3 : SIZE  TlRPOT)  * 

*  RR4 :CLASS  (INPOT)  * 

*  LOCAL  OSS  * 

*  R6:flfl  HANDLE  ARRAY  ENTRY  * 

*  R8 :  -«COM_KSGBUF  ♦ 

*  R1  3:-»C0M_MSGBUF  * 

*********************************  j 

ENTRY 

JOSE  STACK  FOR  MESSAGE! 

0000  030P  SOB  R 1 5, iSIZEOF  COM  MSG 
0002  0010 

0004  &1FD  LD  R13t R15  !  -*C OM.MSGBUF  ! 

IF ILL  COH.MSGBOF  (LOAD  MESSAGE) .  CREATE  MSG 
FRA3E  IS  BASED  AT  ADDRESS  ZERO.  IT  IS 
OVERLAID  ONTO  COM  HSGBOF  FRAME  BY  INDEXING 
EACH  ENTRY  (I.E.  ADDING  10  EACH  ENTRY)  THE 
BASE  ADDRESS  OF  COM.MSGBUFI 

0006  4DD5  LD  CREATE. MSG. CR.CQDE  (R13) , ACBEATE.CODE 

0008  0000 
OOOA  0032 

OOOC  3116  LD  B6,R1(#0)  JINDEX  TO  MM  HANDLE  ENTRY! 

OOOE  0000 

0010  6FD6  LD  CREATE  MSG.CE  MM  HANDLE[ 0 J  (R13) ,B6 

0012  0002 

0014  3116  LD  R6,R1(*2) 

0016  0002 

0018  6FD6  LD  CREATE  MSG.CE  MM  HANDLE[  1  ]  (R1 3)  ,R6 

001 A  0004 

001C  3116  LD  R6,R1{#4) 

00 IE  0004 

0020  6FD6  LD  CREATE  MSG.CE  MM  HANDLER  2 ]  (R13) #R6 

0022  0006 

0024  6FD2  LD  CREATE  MSG.CE  ENTRY  NO(B13),R2 

0026  0008 

0028  5DD4  LDL  CREATE  MSG.CE  CLASS(B13) ,RR4 

002A  OOOC 


290 


002C 

002B 

6PD3 

000  k 

LD 

C REATE_MSG . CE_SI ZE  (R 1 3)  ,R3 

0030 

4108 

LD 

R8 ,R 13 

0032 

0034 

5F00 

018C* 

CALL  PERFORH_IPC  JR8:  -^COB_HSGBOF! 

1RETRIBVE  SOCCESS.COOE  PROS  RETORMED  MESSAGE! 

0036 

8008 

CLR 

RO 

0038 

003A 

6008 

0000 

LOB 

RLO, RET_SUC_CODE. SOC_CODE (H13) 

003C 

003E 

010F 

0010 

ADD 

R 15 f ISIZEOF  COM.MSG  ! RESTORE  STACK  STATE! 

0040 

9E08 

RBI 

0042 

END 

MM_CREATE_ENTRT 
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•toni 


0042 


0042 

0044 

0046 


0048 

004& 

004C 

004E 

0050 

0052 

0054 

0056 

0058 

005A 

005C 

005E 

0060 

0062 

0064 

0066 

0068 

006A 

006C 

006E 

0070 

0072 

0074 

0076 

0078 

0071 

007C 


MU  DELETE  ENTRY  PROCEDURE 


1 


*  INTERFACE  BETWEEN  SEG  MGS 

*  (DELETE  SEG  PROCEDURE)  1ND 

*  N MGR  (DELETE  ENTRY  PROCEDURE)  . 

*  ARRANGES  AND  PERFORMS  IPC. 


*  REGISTER  USE: 

*  PARAMETERS 

*  RO : SU CCESS  CODE (RET) 

*  SI  :HPTR  (INPUT) 

*  R2: ENTRI.NO  (INPUT) 

*  LOCAL  USE 

*  R6:MH  HANDLE  ARRAY  ENTRY 

*  R8:-»CON  HSGBUF 

*  R13:-»COM  HSGBUF 


1 


ENTRY 

!USE  STACK  FOR  HESSAGE! 

030F  SUB  R 15, ISIZEOF  COM  MSG 
0010 

A1FD  LD  R 13,  R 15  !  -»COM_HSGBUF  1 

! FILL  COM  HSGBUF  (LOAD  MESSAGE).  DEL ETE.HSG  FRAME 
IS  BASED~AT  ADDRESS  ZERO.  IT  IS  OVERLAID  ONTO 
COM  HSGBUF  FRAME  BY  INDEXING  EACH  ENTRY  (I.E.  ADD¬ 
ING  TO  EACH  ENTRY)  THE  BASE  ADDRESS  OF  COH.HSGBUP! 


4DD5 

LD 

DELETE_HSG.DE.CODE (fil 3)  , §DELETE_CODE 

0000 

0033 

3116 

LD 

R6  ,R 1  (#0)  ! INDEX  TO  MM.HANDLE  ENTRY! 

0000 

6FD6 

LD 

DELETE_MSG.DE_HH_HANDLE[ 0 ]  (R13) ,R6 

0002 

3116 

LD 

R6,R1  (#2) 

0002 

6FD6 

LD 

DELETE.HSG. DE_MM_HANDLE[ 1 ]  (R13) ,R6 

0004 

3116 

LD 

R6  ,R  1  (#4) 

0004 

6FD6 

LD 

DELETE.HSG. DE_MM_HANDLE[ 2 j  (R 1 3 )  ,R6 

0006 

6FD2 

LD 

DELETE.HSG. DE.ENTRY.NO (R13) ,R2 

0008 

A1D8 

LD 

R8,R13 

5F00 

CALL 

PERFORM  IPC  !R8:  ->C0M  HSGBUF! 

018C* 

! RETRIEVE  SUCCESS.CODE  FROM  RETURNED  MESSAGE! 

8DQ8 

CLR 

RO 

60D8 

LDB 

RLO,RET.SUC_CODE. SUC .CODE  (R13) 

0000 

010F 

ADD 

R15, ISIZEOF  COM.MSG  ! RESTORE  STACK  STATE! 

0010 

9E08 

RET 

END 

MH.DELETE.ENTRY 
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007C  MM  ACTIVATE  PROCEDURE 

j  ********************************* 

*  INTERFACE  BETWEEN  SEG  UGH  * 

*  (HAKE  KNOWN  PROCEDURE)  AND  * 

*  NHGR  (ACTIVATE  PROCEDURE)  .  * 

*  ARRANGES  AND  PERFORHS  IPC.  * 

********************************* 

*  REGISTER  USE:  * 

*  PARAHETERS  * 

*  R1 :  DBR  NO(INPUT)  * 

*  R2:HPTR  (INPUT)  * 

*  R3: ENTRY  NO  ♦ 

*  R4: SEGMENT  NO  * 

*  R1 2: RET  HANDLE  PTR  * 

*  LOCAL  USE  * 

*  R8:  -*COM  HSGBUF  * 

*  R13:-C0H_MSGBUF  * 

*  RETURNS:  * 

*  R0: SUCCESS  CODE  * 

*  RR2 :CLASS  * 

*  R4 : SIZE  * 

********************************* { 

ENTRY 

! U SE  STACK  FOR  MESSAGE! 

007C  030F  SUB  R15,#SIZ£OF  COM..MSG 

007E  0010 

00B0  A1PD  LD  S 13, R15  f  -COM  MSGBUF  I 

1  SAVE  RETURN  HANDLE  POINTER  ! 

0082  93FC  PUSH  BR15,  R12 

!  FILL  CONJJSGBUF  (LOAD  MESSAGE).  ACTIVATE_MSG  FRAME 
IS  BASED  AT  ADDRESS  ZERO.  IT  IS  OVERLAID  ONTO 
COMJISGBOF  FRAME  BY  INDEXING  EACH  ENTRY  (I.E.  ADD- 
I NG~TQ  EACH  ENTRY)  THE  BASE  ADDRESS  OF  COMJiSGBUF! 
0084  4DD5  LD  ACTIVATE_NSG. ACT_CODE(R13)  , #ACTIVATE_CODE 

0086  0000 
0088  0034 

008A  6FD1  LD  ACTIVATE  MSG . A.DBR.NO (R13) ,R 1 

008C  0002 

008E  3126  LD  R6,R2(#0) 

0090  0000 

0092  6FD6  LD  ACTIVATE  MSG. A  M M_HAN DLE[ 0  ] (R 1 3) , R 6 

0094  0004 

0096  3126  LD  R6rR2(«2) 

0098  0002 

009A  6FD6  LD  ACTIVATE  MSG. A_HM_HANDLE[ 1  ] (R 1 3) ,86 

009C  0006 

009E  3126  LD  R6fR2(*4) 

00 AO  0004 

00A2  6FD6  LD  ACTIVATE_NSG. A_MH_HANDLE(  2  ](R13) ,R6 

00A4  0008 

00A6  6EDB  LDB  ACTI VATE.MSG.  A_ENTRY_MO  (HI  3)  ,  RL3 

00A8  000A 
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OOAA  6EDC  LDB  ACTIVATE_HSG.  A_SEGHENT  SO  (B 13)  ,BL4 
00 AC  OOOB 

OOAE  A 108  LO  B8,B13 

OOBO  5P00  CALL  PEBFOBM_IPC  !  (B8:-*C0H  HSGBOP! 

0082  018C' 

!  BESTOBE  BETOBM  HANDLE  POINTEB  i 
00B4  97 PC  POP  B  12f  AB  15 

1  OPDAIE  HH_H ANDLE  ENT BY  ! 

00B6  54D6  LOL  HR6,  B  ACTIVATE  ABG.fi  HH  HANDLE  (B13) 

00B8  0002 

OOBA  5DC6  LDL  HH  HANDLE.  ID  (B12)  ,  BB6 
OOBC  0000 

OOBB  61D6  LD  R6,B  ACTIVATE  ABG.B  HH  HANDLE[  2  ]  (B  13) 

OOCO  0006 

00C2  6PC6  LD  HH.HANDLE.  ENTBY.NO  (B12)  ,  B6 

00C4  0004 

! RETRIEVE  OTHEfi  RETD  BN  ABGOHENTS 1 
00C6  8D08  CL R  BO 

00C8  60D8  LDB  BLO,  B_ACTIVATE_ABG.fi  SCJC  CODE  <R13) 

OOCA  0000 

OOCC  54D2  LDL  RR2,B  ACTIVATE  ABG.B  CLASS  (B 13) 

OOCE  0008 

OODO  61D4  LD  B4,B_ACTIV ATE_ABG. fi_SIZE  (B 13) 

00D2  OOOC 

00D4  010P  ADD  B15#*SIZE0F  COH  HSG  1 BESTOBE  STACK  STATE1 

00D6  0010 

00D8  9E08  BET 

OODA  END  HH  ACTIVATE 


00  DA  &B_DE ACTIVATE  PBOCEDDBE 

]  ********  ******  ******************* 

*  INTERFACE  BETBEEN  SES  MGS  • 

*  (TERMINATE  PROCEDURE)  AND  * 

*  MMGR  (DEACTIVATE  PROCEDURE)  .  * 

*  ARRANGES  AND  PERFORMS  IPC.  * 


*  REGISTER  USE:  * 

*  PARAMETERS  * 

*  RO: SUCCESS  CODE (RET)  * 

*  SI :  DBR  MO  (INPUT)  * 

*  R2:HPTi  (INPUT)  * 

*  LOCAL  USE  * 

*  R6 : MM  HANDLE  ABBA I  ENTBX  * 

*  R8:-*COM_MSGBUF  * 

*  R13:-.COM_MSGBUF  * 

********************************* i 


ENTRY 

!0SE  STACK  POR  MESSAGE! 


OODA 
00  DC 

030F 

0010 

SUB 

R 15, ASIZEOP 

COM_MSG 

OODE 

A1PD 

LD 

R 13, B 15  ! 

-»COM_MSGBUF  ! 

I  FILL  CONJISGBOF  (LOAD  MESSAGE).  DEACTIV ATE.MSG  FRAME 
IS  BASED  AT  ADDRESS  ZEBO.  IT  IS  OVERLAID  ONTO 
COM.MSGBUF  FRAME  BY  INDEXING  EACH  ENTRY  (I.E.  ADD¬ 
ING  TO  EACH  ENTRY)  THE  BASE  ADDRESS  OF  COM  MSGBUF! 


00E0 

00E2 

00E4 

4DD5 

0000 

0035 

LD 

DEACTIV ATE_MSG. DEACT_CODE (R13) , 

ADEACTI VATE_CODE 

00E6 

00E8 

6FD1 

0002 

LD 

DEACTIV ATE_MSG.D_DBB_NO  (HI  3)  ,R1 

OOEA 
00  EC 

3126 

0000 

LD 

R6 ,R2  (AO)  ! INDEX  TO  HMJiANDLE  ENTRY! 

OOEE 

00F0 

6FD6 

0004 

LD 

DEACTIV  ATEJiSG . D _MM _HANDLE£  0 ]  (R 1 3) 

,R6 

00F2 

00F4 

3126 

0002 

LD 

R6,R2  (A2) 

00F6 

00F8 

6FD6 

0006 

LD 

DEACTIV ATE_MSG. D_MM_HANDLE£ 1 ]  (R13) 

,R6 

OOFA 

OOFC 

3126 

0004 

LD 

R6,R2  (A4) 

OOFE 

0100 

6FD6 

0008 

LD 

DEACTIV ATE_MSG.D_MH_HANDLE£ 2 ]  (B13) 

,R6 

0102 

A1D8 

LD 

R8 ,R  1 3 

0104 

0106 

5F00 

018C* 

CALL 

PERFORM_IPC  ! 38:  -COM_MSGBOF! 

t 


{RETRIEVE  SUCCESS.CODE  FROM  RETURNED  MESSAGE! 
CLB  SO 

LDB  RLO,RET_SUC_CODE.SUC_COD£ (R13) 


0108  8D08 
0 1 OA  60D8 
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SlOE  QIOP  IDO  R15,#SIZEO?  COR.RSG  18ESI0RE  STACK  STATE! 

0110  0010 

0112  9E08  RET 

0114  END  SH  ..DEACTIVATE 
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0114  MB  SWAP  IN  PROCEDURE 

I  ********************************* 

*  I  ST ERF  ACE  BETWEEN  SEG  BGR  (SB  * 

*  SWAP  IN  PROCEDURE)  AND  HBGR 

*  (SWAP  IN  PROCEDURE) .  ARRANGES  * 

*  AND  plRFORMS  IPC.  * 

********************************* 

*  REGISTER  USE:  * 

*  PARABETERS  * 

*  RO: SUCCESS  CODE (RET)  * 

*  HI :  DBR  NO  (INPUT)  * 

*  R2:  HPTR  (INPUT)  * 

*  R3: ACCESS  (INPUT)  • 

*  LOCAL  USE  * 

*  B6 : Bfl  HANDLE  ARRAY  EK~RY  * 

*  R8:-C0B  BSGBUF  * 

*  R13:-COH_MSGBUF  * 

********************************* { 

ENTRY 

!OSE  STACK  FOR  MESSAGE! 

0114  030P  SUB  R 15,  iSIZEOF  COM..BSG 
0116  0010 

0118  A1FD  LD  S 13, R 15  !  -COM_MSGBUF  ! 

! FILL  COBJ!SGBUF  (LOAD  MESSAGE).  SWAP_IN_MSG  FRAME 
IS  BASED'AT  ADDRESS  ZERO.  IT  IS  OVERLAID  ONTO 
COM  BSGBUF  FRAME  BY  INDEXING  EACH  ENTRY  (I. E.  ADD¬ 
ING  TO  EACH  ENTRY)  THE  BASE  ADDRESS  OF  COM  BSGBUF! 


01 1A 

4DD5 

LD 

SWAP_IN_MSG. S_IN_CODE (R13) ,#SW AP_IN_C0DE 

01 1C 

0000 

0 1 1E 

0036 

0120 

3126 

LD 

R6 ,R 2  (# 0)  ! INDEX  TO  BM.HANDLE  ENTRY! 

0122 

0000 

0124 

6FD6 

LD 

SWAP_INJ!SG.SIJ!H_HANDLE[0  ](R13)  ,R6 

0126 

0002 

0128 

3126 

LD 

R6,R2(#2) 

012A 

0002 

012C 

6FD6 

LD 

SWAP_IN_MSG.  SI_BM_pHANDLE[  1  ](R13)  ,R6 

012E 

0004 

0130 

3126 

LD 

R6,R2  (#4) 

0132 

0004 

0134 

6FD6 

LD 

SWAP_IN_MSG. SI _HM_HANDLE[ 2  ]  (R1 3) ,R6 

0136 

0006 

0138 

6FD1 

LD 

SWAP_IN_BSG.SI_DBR_NO (R13) ,R1 

013A 

0008 

013C 

6EDB 

LDB 

S WAP_IN_MSG. SI_ACCESS_AUTH  (R13) ,RL3 

013E 

000A 

0140 

A1D8 

LD 

R8,R  13 

0142 

5F00 

CALL 

P ERFORH_IPC  !R8:  ^COM_BSG BUF! 

0144 

018C' 

(RETRIEVE  SUCCESS  CODE  FROM  RETURNED  BBSSAGE ! 

0146 

8D08 

CL  R 

RO 

0148 

60D8 

LDB 

RLO,RET_SUC_CODE.  SUBCODE  (R13) 
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ADD  H15,#SIZE0F  COM_MSG  1 BESTOBE  STICK  STATE! 


0 14A  0000 
0  14C  010F 
014E  0010 
0150  9E08  BET 
0152  END  MM  SWAP  IN 


t  ; 


i 


0152  MM_SHAP_OUT  PROCEDURE 

1  ********************************* 

*  INTERFACE  BETWEEN  SEG  MGR  (SM  * 

*  SWAP_OOT  PROCEDURE)  AND  MMGR  "* 

*  (SNAP  OUT  PHOCEDUBE) .  ARRANGES* 


*  AND  PERFORMS  IPC.  * 

********************************* 

*  REGISTER  USE:  * 

*  PARAMETERS  * 

*  RO:  SUCCESS  CODE  (RET)  * 

*  HI :  DBR  NO  (INPUT)  * 

*  R2:HPTR  (INPUT)  * 

*  LOCAL  USE  * 

*  R6 : MM  HANDLE  ARRAY  ENTRY  * 

*  R8:  -»COM_MSGBUF  * 

*  R13:-»COM  MSGBUF  * 


********************************* | 

ENTRY 

!USE  STACK  FOR  HESSAGEl 


0152 

0154 

030F 

0010 

SUB 

R 15, iSIZEOF 

C0M_MSG 

0156 

A1FD 

LD 

R13,R15  ! 

-*COM_MSGBUF  ! 

! FILL  COM_MSGBUF  {LOAD  MESSAGE).  S WA P_OUT_MS G  FRAME 
IS  BASED“AT  ADDRESS  ZERO.  IT  IS  OVERLAID*"oNTO 
COM  MSGBUF  FRAME  BY  INDEXING  EACH  ENTRY  (I.E.  ADD¬ 
ING  TO  EACH  ENTRY)  THE  BASE  ADDRESS  OF  COM  MSGBUF! 


0158 

4DD5 

LD 

SWAP_0UT_M3G.S_0UT_C0DE(R13) ,  #SBAP_OUT_CODS 

0  15A 

0000 

015C 

0037 

015E 

3126 

LD 

R6,R2(*0)  ! INDEX  TO  MM_HANDLE  ENTRY! 

0160 

0000 

0162 

6FD6 

LD 

SNAP_O0T_HSG.SO_MM_HANDLE[ 0](R13) ,B6 

0164 

0004 

0166 

3126 

LD  1 

R6 ,32  (#2) 

0166 

0002 

016  A 

6FD6 

LD 

SWAP_OUT_MSG .SO_MM_HANDL£[  1](R13)  ,B6 

0 16C 

0006 

0  16E 

3126 

LD 

R6,R2 (#4) 

0170 

0004 

0172 

6FD6 

LD 

SHAP_OUT_MSG.SO_MM_HANDLE[ 2](R13)  ,R6 

0174 

0008 

0176 

6FD1 

LD 

SNAP_0UT_MSG.S0_DBR._80  (R13)«R1 

0178 

0002 

0 17A 

A1D8 

LD 

R8,R  13 

017C 

5FC 

CALL 

PERF08M_IPC  !R6:  *COM_MSGBUFI 

017E 

018C 

{RETRIEVE  SUCCESS  CODE  FROM  RETURNED  MESSAGE! 

0180 

8D08 

CLR 

RO 

0182 

60  D8 

LDB 

RLO, RET_SUC_CODE. SUC_CODE  (R13) 

0184 

0000 

0186 

010F 

ADD 

R 15, fSIZEOF  COM.MSG  ! RESTORE  STACK  STATE! 

0188 

0010 
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-rua. 


0  18A  9E08  BET 

018C  END  88  SWAP  OUT 
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m 


018C  PERFORM. IPC  PROCEDURE 

j  ************************************* 

*  SERVICE  ROUTINE  TO  ARRANGE  AND  * 

*  PERFORM  IPC  WITH  THE  MEM  MGR  PROC  * 

************************************* 

*  REGISTER  USE:  * 

*  PARAMETERS  * 

*  R8:  -COM  MSG  (INPUT)  * 

*  LOCAL  USE-  * 


*  HI , 

R2:  WORK  REGS  * 

*  R4 : 

-G_AST_LOCK  * 

*  HI  3 

:  -.COM  MSGBUF  * 

*************************************  t 

ENTRY 

018C 

93FD 

PUSH 

3R15/R13  1-.COM  MSGBUF! 

018E 

5F00 

CALL 

GET_CPU.no  !RET-R1:CPU_NO! 

0190 

0000* 

0192 

A112 

LD 

R2,R1 

0194 

6121 

LD 

R 1  v  MM.CPU.TBL  (R2)  IMM.VP.ID! 

0196 

0000 1 

0198 

7604 

LOA 

R4,G_AST_LOCK 

019A 

0000* 

0  19C 

5F00 

CALL 

K.LOCK 

0 19E 

0000* 

0  1  AO 

5F00 

CALL 

SIGNAL  !R1: MM.VP.ID#R8:-COH_MSGBUF! 

01A2 

0000* 

01A4 

97FD 

POP 

R13,9R15 

01A6 

AIDS 

LD 

R8,R13  I-.COM.  MSGBUF! 

0 1 A8 

93FD 

PUSH 

9815,813 

0  1 AA 

5F00 

CALL 

HA  IT  !R  8:  -.COM.  MSGBUF! 

01  AC 

0000* 

0  1 AE 

7604 

LDA 

R4,G_AST_LOCK 

01B0 

0000* 

01B2 

5F00 

CALL 

K. UNLOCK 

01B4 

0000* 

01B6 

97  FD 

POP 

R13,9R15 

01B8 

9E08 

RET 

01  BA 

END 

PEHFORH.IPC 

I 
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0  1  BA 


PBOC BOOBS 


HH_ ALLOCATE 
! *********** 

*  ALLOCATES  BLOCKS  OF  CPU 

*  LOCAL  HEHOBY.  EACH 

*  BLOCK  CONTAINS  2S6 

*  BYTES  OF  NENOBY. 


*  PABAHETEBS:  * 

*  B3:  *  OF  BLOCKS  * 

*  BETOBNS:  * 

*  R2:  STABTING  AODB  * 

*  LOCAL:  * 

*  B4:  BLOCK  POINTEB  * 

**************************! 

ENTBY 

!  NOTE:  THIS  PBOCED OBE  IS  ONLY  A  STOB 
OP  THE  OBIGINALLY  DESIGNED  HEHOBY 
ALLOCATING  HECHANISH.  IT  IS  USED 
BY  THE  PBOC ESS  HANAGEHENT  DEHONSTBATION 
TO  ALLOCATE  CPO  LOCAL  HEHOBY  FOB  ALL 
HEHOBY  ALLOCATION  BEQOIBEHENTS .  IN  AN 
ACTUAL  SASS  ENVIBONHENT,  THIS  HOOLD 
BE  BETTEB  SEBVED  TO  HATE  SEPABATE 
ALLOCATION  PBOCEDOBES  FOB  KEBNEL  AND 
SUPEBVISOB  NEEDS.  (E.G.,  KEBNEL  ALLOCATE 
AND  SOPEBYISOB  ALLOCATE)  .  1 

J  COHPOTE  SIZE  OF  HEHOBY  BEQDESTED  ! 

01  BA  B331  SLL  R3,  tBLOCK.SIZB 

0 1 BC  0008 

!  COHPOTE  OFFSET  OF  HEHOBY  THAT  IS 
TO  BE  ALLOCATED  ! 

0  IBS  6104  LD  34,  NEZT.BLOCK  ! OFFSET! 

0 ICO  0F00 ' 

0 1C2  7642  LDA  R2,  HEH_P00L(B4)  1STABT  ADDBI 

0 1C4  0000* 

0 1C6  8134  ADD  B4,  B3  ! UPDATE  OFFSET! 

!  UPDATE  OPFSET  IN  SECTION  OF  AVAILABLE 
HEHOBY  TO  INDICATE  THAT  CUBBENTLY 
REQUESTED  HEHOBY  IS  NOB  ALLOCATED  1 


0  1C8 
01CA 

6F04 

0F00* 

LD 

NEZT.BLOCK,  B4  1SAVE  OFFSET! 

01CC 

9E08 

BET 

0  ICE 

END  HH.ALLOCATE 
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0  ICE  MM_TICKET  PROCEDURE 

i ***************************** 

*  RETURNS  CURRENT  VALUE  OF  * 

*  SEGMENT  SEQUENCER  AND  * 

*  INCREMENTS  SEQUENCER  VALUE* 

*  FOR  NEXT  TICKET  OPERATION  * 
***************************** 

*  PARAMETERS:  * 

*  R1 :  SEG  HANDLE  PTR  * 

*  RETURNS:  * 

*  RR4 :  TICKET  VALUE  * 

*  LOCAL  VARIABLES:  * 

*  RR6:  SEQUENCER  VALUE  * 

*  R8:  G_AST  ENTBI  *  * 

***************************** l 

ENTRY 

1  SAVE  HANDLE  PTR  ! 


0  ICE 

93F1 

PUSH 

3R15,  R1 

!  LOCK  G  AST  ! 

0  IDO 

7604 

LDA 

R4,  G_AST_LOCK 

01D2 

0000* 

01D4 

5FOO 

CALL 

K_LOCK 

0  1D6 

0000* 

!  RESTORE  HANDLE  PTR  ! 

01D8 

97F1 

POP 

B 1 ,  3R1 5 

!  GET 

G_A$T  ENTRY  #  ! 

0  IDA 

6118 

LD 

R8 ,  MM.HANDLE. ENTRY.NO (R1) 

01  DC 

0004 

1  GET 

TICKET  VALUE  ! 

01DE 

5486 

LDL 

BR6 ,  G_AST. SEQUENCER  (B8» 

0  1E0 

0014* 

!  SET 

RETURN  REGISTER  VALUE  ! 

01E2 

9464 

LDL 

RR4,  RR6 

I  ADVANCE  SEQUENCER  FOB  NEXT 
TICKET  OPERATION! 


01E4  1606 
0 1E6  0000 
0 1E8  0001 

0 1 EA  5D86 
0 1  SC  0014* 


0 1  EE  91F4 
0 1F0  7604 
01F2  0000* 
01F4  5F00 
0 1F6  0000* 


ADDL  RR6,  *1 


!  SAVE  NEW  SEQUENCER  VALUE  IN  G 
LDL  G^AST.  SEQUENCER  (R8)  ,  BR6 

!  UNLOCK  G.AST  ! 

!  SAVE  RETURN  VALUES  ! 

PUSHL  iR  15,  RR4 
LDA  R4,  G_ASI_LQCK 

CALL  K.UNLOCK 

!  RETRIEVE  RETURN  VALUES  ! 

POPL  RR4,  3R15 
RET 

END  HH  TICKET 


AST  ! 


0 1F8  95F4 
0 1  FA  9E08 
0 1FC 
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01  PC 


HH  BEAD  EVENTCOUNT  PBOCEDOHE 
I  ******************************* 

*  BEADS  CUBBENT  VALUE  OF  THE  * 

*  EVENTCOUNT  SPECIFIED  BY  THE  * 

*  USEB.  * 


*  PABAHETEBS:  * 

*  B1:  SE6  HANDLE  PTC  * 

*  B2:  INSTANCE  (EVENT  *)  * 

******************************* 

*  BETOBNS:  * 

*  BB4:  SVENTCOONT  VALUE  * 

******************************* 

*  LOCAL  VABIABLES:  * 

*  BB6:  SEQUENCES  VALUE  * 

*  B8:  G_AST  ENTBY  #  * 

******************************* j 


ENTBY 

!  SAVE  INPUT  PABAHETEBS  ! 


0  1FC 

93F1 

PUSH 

SB15,  B 1 

01FE 

93F2 

PUSH 

SB15,  B2 

!  LOCK  G_AST  1 

0200 

7604 

LDA 

B4 ,  G_AST_LOCK 

0202 

0000* 

0  204 

5F00 

CALL 

K_LOCK 

0206 

0000* 

!  BESTOBE  INPUT  PABAHETEBS  t 

0208 

97F2 

POP 

B2  ,  ifil 5 

020A 

97  FI 

POP 

B  1 ,  SRI 5 

I  GET 

G  AST  ENTBY  *  ! 

020C 

6118 

LD 

as,  NH  HANDLE.  ENTBY  NO(B1) 

020E 

0004 

!  BEAD  EVENTCOUNT  ! 

!  CHECK  HHICH  EVENT  •  ! 

IF  B2 

0210 

0B02 

CASE 

•INSTANCE 1  THEN 

0212 

0001 

0214 

5E0E 

0216 

0224* 

0218 

5484 

LDL 

BH4,  G_AST.EVENT1 (B8) 

021A 

0018* 

02 1C 

2100 

LD 

BO,  •SUCCEEDED 

021E 

0002 

0220 

5E08 

CASE 

•INSTANCB2  THEN 

0222 

023C* 

0224 

0B02 

0226 

0002 

0228 

5E0E 

0  22A 

0238* 

022C 

5484 

LDL 

BB4,  G_AST .E VBNT2 (B8) 

022E 

001C* 

0230 

2100 

LD 

BO,  •SUCCEEDED 

0232 

0002 

304 


0234  5E08  ELSE  fINVALID  INPOT! 

0236  023C* 

0238  2100  LO  RO,  VINVALID  INSTANCE 

023A  005F 

FI 

!  NOTE:  NO  VALDE  IS  BETOSNEO  IF 
OSES  SPECIFIED  INVALID  EVENT  »! 
!  SAVE  HETOHN  VALDES  ! 

023C  91F4  POSHL  iR15,  BB4 

!  UNLOCK  G  AST  ! 

023E  7604  LDA  H4 ,  G  AST  LOCK 

0240  0000* 

0242  5F00  CALL  K.ONLOCK 

0244  0000* 

!  RESTORE  RETORN  VALOES  1 
0246  95F4  POPL  RR4,  NR15 

0248  9E08  RET 

024A  END  BN  READ  EVENTCOONT 
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024A  MM.ADVANCE  PROCEDURE 

I *********************************** 

*  DETERMINES  G.AST  OFFSET  FROM  * 

*  SEGMENT  HANDLE  AND  INCREMENTS  * 

*  THE  INSTANCE  (EVENT  •)  SPECIFIED  * 

*  BT  THE  CALLER.  THIS  IN  EFFECT  * 

*  ANNOUNCES  THE  OCCURRENCE  OF  THE  * 

*  EVENT.  THE  NEH  VALUE  OF  THE  * 

*  EVENTCOUNT  IS  RETURNED  TO  THE  * 

*  CALLER.  * 

*********************************** 

*  PARAMETERS:  * 

*  HI:  HANDLE  POINTER  * 

*  H2:  INSTANCE  (EVENT  #)  * 

*********************************** 
«  RETURNS:  * 

*  HR 2:  NEH  EVENTCOUNT  VALUE  * 

*********************************** 1 

ENTRY 

1  SAVE  INPUT  PARAMETERS  t 
024A  93 FI  PUSH  8R15,  R1 

024C  93F2  PUSH  BR15,  R2 

!  LOCK  G  AST  ! 

024E  7604  LDA  R4 ,  G  AST. LOCK 
0250  0000* 

0252  5F00  CALL  K.LOCK 

0254  0000* 

!  RESTORE  INPUT  PARAMETERS  ! 

0256  97F2  POP  R2,  «R15 

0258  97F 1  POP  R1,  SR15 

!  GET  G  AST  OFFSET  ! 

025A  6114  LD  R4,  MM  HANDLE. ENTRY  NO(R1> 
025C  0004 

!  DETERMINE  INSTANCE  I 
IF  R2 

025E  0B02  CASE  IINSTANCE1  THEN 
0260  0001 
0262  5E0E 
0264  027C* 

0266  5442  LDL  RR2,  G  AST . EVENT  1 (R4) 

0268  0018* 

026A  1602  ADDL  RR2,  *1 

026C  0000 
026E  0001 

!  SAVE  NEH  EVENTCOUNT  ! 

0270  5D42  LDL  G  AST .EVENT1  (R4) ,  RR2 

0272  0018* 

0274  2100  LD  RO,  iSUCCEED ED 

0276  0002 

0278  5E08  CASE  IINSTANCE2  THEN 
027A  029B' 

027C  0B02 
027E  0002 
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0280  5E0E 
0282  029A* 

0284  5442  LOL  882,  G  AST. EVENT2 (84) 

0286  001C* 

0288  1602  ADDL  RB2,  *1 

028A  0000 
0  28C  0001 


!  SAVE  MEM  EVENTCOUNT  ! 


028E 

0290 

5D42 

00 1C* 

LDL 

G_AST.EVBNT2 (84) ,  882 

0292 
0  294 

2100 

0002 

LD 

80,  # SUCCEED ED 

0296 

0298 

5E08 

029E* 

ELSE 

{INVALID  INPUT! 

029A 

2100 

LD 

RO,  tINVALID.INSTANCE 

029C  005P 

PI 

!  80TB:  AN  INVALID  INSTANCE  VALUE 
KILL  NOT  APFECT  EVENT  DATA  ! 

!  UNLOCK  G  AST  ! 

0 29E  7604  LDA  84,  G  AST  LOCK 

0 2A0  0000* 

02A2  5F00  CALL  K  UNLOCK 

02A4  0000* 

02 A6  9E08  HET 

02A8  END  MH— ADVANCE 

END  DISTHN 
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Appendix  D 

Gif E  KEEPER  LISTINGS 


Z8000ASH  2.02 

LOC  OBJ  CODS  STHT  SOURCE 

KERNEL_GATE_KEEPER 

ILISTOH  STTT 

CONSTANT 

ADVANCE  CALL 
AVAIT  CALL 
CREATE_SEG_CALL 

deletb_seg“call 

HAKE  KNOWN  CALL 

BEAD  CALL 

SN_SWAP_IN_CALL 

SM  SWAP~ OUT  CALL 

TERHINATE  CALL 

TICKET  CALL 

HBITE_CALL 

WRITSLN  CALL 

CBLF.CALL 

WRITE 

WRITELN 

CBLF 

MONITOR 

R  EG IS  TER  _B LOC  K 
TRAP_CODE_OFFSET 
I N?ALID_KERNEL_ENTRI 

GLOBAL 

3  ATE_KEEPER_ENTRT 

EXTEBNAL 

ADVANCE 

AWAIT 

CREATE  SEG 
DELETE  SEG 
HAKE  KNOWN 
READ 

SM_SWAP  IN 
SH  SNAP’OUT 
TEE  HI  NATE 
TICKET 
KERNEL  EXIT 


STATEHENT 

NODDLE 


a  1 
»  2 
a  3 
a  4 
a  5 
=  6 
=  7 
a  8 

*  9 
a  10 
a  11 

*  12 
*  13 

a  X0PC8  I  PRINT  CHAR! 
a  SOPCO  ! PRINT  HSG! 
a  X0PD4  ICAR  RET/LINE  FEED! 
a  XA902 
»  32 
a  36 
a  XBAD 


LABEL 


PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

LABEL 


308 


INTERNAL 

{SECTION  KEENEL_GATE_PROC 
0000  GATE_KEEPER_MAIN  PROCEDURE 

ENTRY 

GATE  KEEPER_ENTRY: 

!  SATE  REGISTERS  1 

0000  030?  SOB  R 15,  ifiEGISIEB  BLOCK 
0002  0020 

0004  1CF9  LON  8R15,  HI,  *16 

0006  010? 

i  SATE  NSP  ! 

0008  93F2  POSH  1R15,  R2 

OOOA  7D27  LDCTL  R2,  NSP 

!  RESTORE  INPOT  REGISTERS  ! 

OOOC  2DP2  EX  R2,  3R15 

!  SATE  REGISTER  2  ! 

OOOE  93F2  POSH  3R15,  R2 

!  GET  SYSTEM  TRAP  CODE  ! 

0010  31P2  LO  R2,  R15(#TRAP  CODE  OFFSET) 

0012  0024 

!  REMOTE  SYSTEM  CALL  IDENTIFIER  FROM 
SYSTEM  TRAP  INSTROCTION  1 
0014  8C28  CL RB  RH2 

!  NOTE:  THIS  LEATES  THE  OSER  VISIBLE 
EXTENDED  INSTROCTION  NONBER  IN  R2  ! 

!  DECODE  AND  EXEC OTB  EXTENDED  INSTROCTION  ! 
IF  R2 

!  NOTE:  THE  INITIAL  TALOE  FOR  REGISTER  2 
WILL  BE  RESTORED  HHEN  THE  APPROPRIATE 
CONDITION  IS  FOOND  I 
0016  0B02  CASE  # ADVANCE  CALL  THEN 
0018  0001 
001A  5E0E 
001C  0028* 

001E  97F2  POP  R2,  »R15 

0020  5F00  CALL  ADTANCE 

0022  0000* 

0024  5E08  CASE  *AHAIT_CALL  THEN 

0026  010C' 

0028  0B02 
002A  0002 
002C  5E0E 
002E  003A* 

0030  97F2  POP  R2,  3R15 

0032  5FOO  CALL  AHAIT 

0034  0000* 

0036  5E08  CASE  iCREATE  SEG  CALL  THEN 
0038  010C* 

003A  0B02 
003C  0003 
003E  5 BOB 
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0040  0C  ’ 
0042  97P2 
0044  5P00 
0046  0000* 
0048  5E08 
004A  010C* 
004C  0802 
004E  0004 
0050  5B0S 
0052  005E' 
0054  97P2 
0056  5P00 
0058  0000* 
005A  5E08 
005C  010C' 
005E  0802 
0060  0005 
0062  5E0E 
0064  0070' 
0066  97P2 
0068  5P00 
006A  0000* 
006C  5B08 
006E  010C* 
0070  0B02 
0072  0006 
0074  5E0E 
0076  0082* 
0078  97P2 
007A  5P00 
007C  0000* 
007E  5E08 
0080  010C‘ 
0082  0B02 
0084  0007 
0086  5E0E 
00 88  0094* 
0Q8A  97P2 
008C  5 POO 
008E  0000* 
0090  5E08 
0092  010C' 
0094  0B02 
0096  0008 
0098  5E0E 
009A  00 A6 1 
009C  97P2 
009E  5P00 
OOAO  0000* 
00A2  5E08 
00A4  010C» 
00A6  0B02 
00A8  0009 
OOAA  5E0E 


POP  82,  881 5 
CALL  CRBATE_S£G 

CASE  #DELETE_SEG_CALL  THEM 


POP  R2,  8815 
CALL  DELETE^SEG 

CASE  #HAKE_KHOiN_CALL  THEM 


POP  82,  8815 
CALL  HAKE_KHO«H 

CASE  #8EAD_CALL  THEM 


POP  82,  8815 
CALL  BEAD 

CASE  *SH_SIAP_III_>CALL  THEM 


POP  82,  8815 
CALL  SH_SffAP_Ill 

CASE  tSH^SIAP^OOT^CALL  I8EB 


POP  82,  8815 
CALL  SH_SHAP_OOI 

CASE  #TE8aiHATE_CALL  THEM 
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00  AC 

OOB8' 

00  AE 

97P2 

POP  R2,  3R1 5 

00B0 

5P00 

CALL  TERMINATE 

00B2 

0000* 

00B4 

5E08 

CASE  §TICKET_CALL  THEN 

00B6 

010C* 

00B8 

0B02 

OOBA 

OOOA 

OOBC 

5E0E 

OOBB 

OOCA* 

OOCO 

97P2 

POP  R2,  3R15 

00C2 

5P00 

CALL  TICKET 

0  0C4 

0000* 

00C6 

5E08 

CASE  tURITS.CALL  THEN 

00C8 

010C* 

OOCA 

0B02 

OOCC 

OOOB 

OOCE 

SEOE 

OODO 

OODC* 

0002 

97P2 

POP  R2,  SRI  5 

0004 

5P00 

CALL  WRITE 

00D6 

0PC8 

0008 

5E08 

CASE  #HRITELN_CALL  THEN 

OODA 

010C* 

00  DC 

0B02 

OODE 

OOOC 

OOEO 

5E0E 

00E2 

OOEE* 

00E4 

97P2 

POP  R2,  3B15 

00E6 

5P00 

CALL  NRITELN 

00E8 

OPCO 

OOEA 

5E08 

CASE  #CRLF_CALL  THEN 

00  EC 

010C* 

OOEE 

0BO2 

OOFO 

0000 

00P2 

5E0E 

00P4 

0100* 

00P6 

97P2 

POP  R2,  dRI 5 

0QP8 

5P00 

CALL  CRLP 

OOPA 

0PD4 

OOPC 

5E08 

ELSE  ! INVALID  KERNEL  INVOCATION! 

OOPS 

010C* 

!  RETURN  TO  MONITOR  ! 

!  NOTE:  THIS  RETURN  TO  MONITOR  IS 
POR  STUB  USE  ONLY.  AN  INVALID 
KERNEL  INVOCATION  MOULD  NORMALLY 
RETURN  TO  USER.  ! 

0100 

7601 

LOA  R 1 ,  $ 

0102 

0100* 

0104 

2100 

LD  RO,  iINVALI D_KERNEL_ENTRY 

0106 

OBAD 

0108 

5P00 

CALL  MONITOR 

010A 

A902 

PI 
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010C  93F1 


!  SAVE  REGISTERS  ON  KERNEL  STACK  1 
!  SAVE  HI  1 
POSH  3R15,  R 1 

!  GET  ADDRESS  OP  REGISTER  BLOCK  1 
0 1 0E  34 PI  LDA  HI,  R15  (#4) 

0110  0004 

!  SAVE  REGISTERS  IN  REGISTER  BLOCK 
ON  KERNEL  STACK.  ! 

0112  1C19  LDM  3R1,  HI,  *16 
0114  0 10F 


0116  2DP1 

0118  33P1 
011A  0004 

011C  97P1 

0 1 1E  33P1 
0120  00 IE 


!  RESTORE  R1  BOT  MAINTAIN  ADDRESS 
OF  REGISTER  BLOCK  1 
EX  R1,  SRI  5 
!  SAVE  B1  ON  STACK  1 
LD  R  15  ( #4)  ,  R 1 

!  RESTORE  REGISTER  BLOCK  ADDRESS  1 
POP  R  1 ,  SR  15 
!  SAVE  VALID  EXIT  SP  VALOE  ! 

LD  R 15 (#30)  #  R 1 


!  EXIT  KERNEL  BT  MEANS  OP  HARDWARE 
PREEMPT  HANDLER  ! 

0122  5E08  JP  KERNEL_EXIT 
0124  0000* 

0126  END  GATE  KEEPER  MAIN 

END  KERNELJ3ATB_ KEEPER 
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Z8000 ASH  2.02 

LOC  OBJ  CODE  STMT  SOURCE  STATEMENT 
USER  GATE  MODULE 


{LISTON  $TT Y 


CONSTANT 

ADVANCE  CALL  1 

AWAIT .CALL  :*  2 

creatI_seg_call  :*  3 

DELETE  SEG.CALL  :  =  4 

MAKE.KNOWNicALL  :=  5 

READ“cALL  “  :  *  6 

SM  SWAP. IN .CALL  :*  7 

SM.SW  AP.OUT.CALL  : =  8 

TERMINATE. CALL  :*  9 

TICKET.C ALL  :*  10 

WRITE.CALL  : =  11 

WRITELN.CALL  :=  12 

CRLP  CALL  :=  13 


GLOBAL 

{SECTION  USER  GATE  PROC 


0000  ADVANCE  PROCEDURE 

i ************************ 

*  PARAMETERS:  ♦ 

*  HI -.SEGMENT  #  * 

*  R2: INSTANCE  (ENTRY#)* 

************************ 

*  RETURNS:  * 

*  RO: SUCCESS  CODE  * 

************************ | 

ENTRY 

0000  7F0 1  SC  # ADVA NCE.C ALL 

0002  9E08  RET 

0004  END  ADVANCE 


0004 


0004  7P0 2 
0006  9E08 
0008 


AWAIT  PROCEDURE 

{ ************************ 

*  PARAMETERS:  * 

*  R 1 : SEG MENT  #  * 

*  R2: INSTANCE  * 

*  RR4: SPECIFIED  VALUE  * 

************************ 

*  RETURNS:  * 

*  RO: SUCCESS  CODE  * 

************************ i 

ENTRY 

SC  # AWAIT  CALL 
RET 

END  AWAIT 
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0008 


0008  7P03 
000A  9E08 
OOOC 


CBEATE_SEG  PBOCEDUEE 

]  **********************41* 

*  PARAMETERS:  * 

*  HI: MENTOR  SEG  NO  * 

*  R2i ENT  RY_NO  ”  * 

*  S3: SIZE  * 

*  RR4: CLASS  * 

************************ 

*  RETURNS:  * 

*  RO:SUCCESS  CODE  * 

************************  j 

ENTRY 

SC  iCREATZ  SEG  CALL 
RET 

END  CREATE  SEG 


OOOC 


OOOC  7F04 
OOOE  9E08 
0010 


D£LETE_SEG  PROCEDURE 

i  ************************ 

*  PARAMETERS:  * 

*  HI: MENTOR  SEG  NO  * 

*  R2:ENTRY_N0  * 

************************ 

*  RETURNS:  * 

*  RO: SUCCESS  CODE  * 

************************  j 

ENTRY 

SC  #DELETE_SEG  CALL 
RET 

END  DELETE  SEG 


0010 


0010  7P05 
0012  9E08 
0014 


NAKEJCNOHN  PROCEDURE 

•  ************************ 

*  PARAMETERS:  * 

*  R 1 : MENTOR_SEG  NO  * 

*  R2:ENTRY_NO  * 

*  R3: ACCESS  DESIRED  * 

************************ 

*  RETURNS:  * 

*  HO: SUCCESS  CODE  * 

*  R 1: SEGMENT  *  * 

*  R2: ACC  ESS  ALLOWED  * 

************************ | 
ENTRY 

SC  #  MAKE_KNOHN_CALL 
RET 

END  MAKE  KNOWN 


0014  READ  PROCEDURE 

I  ************************ 

*  PARAMETERS:  * 

*  RIsSEGMENT  #  * 

*  R2:INSTANCE  * 
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*  RETURNS :  * 

*  R 0 : SUCCESS  CODE  * 

*  RR4 : EY  ENTCOUNT  * 

**** ******************** ( 

ENTRY 

0014  7F06  SC  #READ  CALL 

0016  9E08  RET 

0018  END  READ 


0018  SM_S»AP_IN  PROCEDURE 

j  ************************ 

*  PARAMETERS:  * 

*  R 1 : SEG WENT  #  * 

************************ 

*  RETURNS:  * 

*  RO: SUCCESS  CODE  * 

************************ | 

ENTRY 

0018  7F07  SC  #SM_SMAP_I N  CALL 

00 1 A  9E03  RET 

001C  END  SM  SNAP  IN 


00 1C  SM_SWAP_OUT  PROCEDURE 

•  ************************ 

*  PARAMETERS:  * 

*  R1 : SEGMENT  #  * 

************************ 

*  RETURNS:  * 

*  RO: SUCCESS  CODE  * 
************************ | 
ENTRY 

00 1C  7F08  SC  #SM_SWAP_OUT_CALL 

00  IE  9E08  RET 

0020  END  SM  SNAP  OUT 


0020  TERMINATE  PROCEDURE 

{ ************************ 

*  PARAMETERS:  ♦ 

*  R1 : SEGMENT  *  * 

************************ 

*  RETURNS:  * 

*  RO: SUCCESS  CODE  * 

************************ | 
ENTRY 

0020  7F09  SC  ITERMINATE  CALL 

0022  9E08  RET 

0024  END  TERMINATE 


0024  TICKET  PROCEDURE 

I  ************************ 

*  PARAMETERS:  * 

*  R 1 : SEG  SENT  #  * 


*  RETURNS: 
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*  SO: SUCCESS  CODE  * 

*  RR4: TICKET  TALUS  * 

A*********************** | 

ENTRY 


0024 

7P0A 

SC  #TICKET 

_CALL 

0026 

9E08 

BBT 

0028 

END  TICKET 

0028 

WRITS 

ENTRY 

PROCEDURE 

0028 

7P0B 

SC  # WRITE. 

CALL 

002A 

9E08 

RET 

002C 

END  WRITE 

002C 

WRITSLN 

ENTRY 

PROCEDURE 

002C 

7P0C 

SC  iWRITELN  CALL 

002E 

9E08 

RET 

0030 

END  WRITELN 

0030 

CRLP 

ENTRY 

PROCEDURE 

0030 

7P0D 

SC  iCRLF  CALL 

0032 

9E08 

RET 

0034 

END  CRLP 
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Appendix  B 

BOOT  ST  B AP_LO  AD  EB  LISTINGS 


Z8000ASH  2.02 

LOC  OBJ  CODE  ST NT  SOUBCE  STATEMENT 

BOOTSTB AP_LOADEB  MODULE 

SLISTON  $TTY 
CONSTANT 


!  ********  SYSTEM  PABAMETEBS  ********  | 


NB_CPU 
N  fi~VP 

Nb'aVAIL  vp 

MAX  DBB  NB 
STACK  SEG 
STACK  SEG  SIZE 
STACK  BLOCK 


2 

NB_CPU*4 
NB  CPU *2 
10“ 

1 

*100 

STACK  SEG.SIZE/256 


!  *  *  OFFSETS  IN  STACK  SEG  *  *  ! 

S IACK_BASE  :*  STACK  SEG  SIZE-110 
STATUS_BEG_BLOCK: =  STACK  SEG  SIZE-*  10 
INTEBBUPT  FBAME  :»  STACK  BASl-4 


I NTEBBUPT_BEG 

N  S  P 

F_C_W 

!  ******  SYSTEM 
ON 
OFF 
BEADY 
NIL 

INVALID 
K SB N EL  FCW 
AVAILABLE 
ALLOCATED 
SC_OFFSET 

TYPE 


:=  INT£BBUPT_FBAME-34 
:*  INTEBBUPT_BEG-2 
;s  ST ACK_SEG_SI ZE-*E 

CONSTANTS  ******  ! 

:  =  *FFFF 
:  =  0 
:*  1 

:*  *FFPF 
:»  *EEEE 
:*  *5000 
:»  0 
:»  XFF 
:»  12 


MESSAGE  AfiBAY  [16  BYTE] 
ADDBESS  HOBD 
MMJTP_ID  HOBD 
VP_INDEI  INTEGEB 

MSG_INDEX  INTEGEB 
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MSG  TABLE  RECORD 
£  MSG  MESSAGE 

SEEDER  VP  INDEX 

NEXT  MSG  MSG  INDEX 

FILLER  ARRAY  [5,  HORD] 

] 

VPJTABLE  RECORD 
[  DBR  ADDRESS 

PRI  HORD 

STATE  HORD 

IDLE  FLAG  HORD 

PREEMPT  HORD 

PHYS  PROCESSOR  HORD 

NBXT~READY  VP  VP.INDBX 

MSG  LIST  MSG  INDEX 

EXT~ID  HORD 

FILLER  1  ARRAYC  7,  HORD] 

] 

EXTERNAL 

GET  DBR  ADDR  PROCEDURE 

CREATE_STACK  PROCEDURE 

LIST  INSERT  PROCEDURE 

ALLOCATE  MHO  PROCEDURE 

UPDATE  MHO  IMAGE  PROCEDORE 
HH  ALLOCATE  PROCEDORE 

HH  ENTRY  LABEL 

IDLE  ENTRY  LABEL 

PREEMPT  RET  LABEL 

BOOTSTRAP  ENTRY  LABEL 
GATE  KEEPlfi  ENTRY  LABEL 
NEXTIbLOCK  HORD 

MH_CPU_TBL  AREAY[ NR_CPO  MM^VP.ID] 

7PT  RECORD 

[  LOCK  HORD 

RUNNING  LIST  ARRAY[ NR_CPU  HORD] 

BEADY  LIST  ABBAY[  NR  CPU  HORD] 

FREE  LIST  MSG  INDEX 

VIRTIiNT_VEC  ARRAYC  1,  ADDRESS  ] 

FILLER  2~  HORD 

VP  ARRAY  [NR  VP,  VP  TABLE] 

MSG  Q  ARRAY  [NR  VP,  MSG  TABLE] 

3 
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EXT_VP_LIST  AHaAICNB  AVAIL  VP  WORD  ] 
HEXTJLVAILjnia  ARR AY[  MAX_DBB_NB  BITE] 

PBOS  BECOBO 

[PHIS_CPO_IO  WORD 
LOG_CPO_ID  INTEGEB 
VP  MB  HOBO 

IDLE  VP  VP  INDEX] 


I  STERNAL 

SSECTION  L0ADE8_DATA 

!  NOTE:  THESE  OECLABATIO NS  HILL  NOT  HOBK 
IN  A  TRUE  HULTI PROCESSOR  ENVIRONMENT  AS 
THE!  ABE  SUBJECT  TO  A  "CALL."  THEI  HOST 
BE  DECLABEO  AS  A  SHABED  GLOBAL  DATABASE 
HITB  "RACE"  PROTECTION  (E.G.,  LOCK),  t 

NEXT_AVAIL_VP  INTEGEB 
NEXTEXT  VP  INTEGEB 


0000 

0002 


ASECTION  LOADER  INT 
INTERNAL 

0000  BOOTSTRAP  PROCEDURE 

|****************************«#** 

*  CREATES  KERNEL  PROCESSES  AND  * 

*  INITIALIZES  KERNEL  DATABASES. * 

*  INCLUDES  INITIALIZATION  OP  * 

*  VIRTUAL  PROCESSOR  TABLE,  * 

*  EXTERNAL  VP  LIST,  AND  MMU  * 

*  IMAGES.  ALLOCATES  MttU  IMAGE  * 

*  AND  CREATES  KERNEL  DOMAIN  * 

*  STACK  FOR  KERNEL  PROCESSES.  * 

****************************** **I 

ENTRY 

!  INITIALIZE  PROS  AND  HHU  POINTER  ! 

!  NOTE:  THE  FOLLOWING  CONSTANTS  ARE 
ONLT  TO  BE  INITIALIZED  ONCE.  THIS 
WILL  OCCUR  DURING  SYSTEM  INITIALIZATION! 


0000 

4D05 

LD 

PRDS.  PHYS_CPU_ID,  #XFFPP 

0002 

0000* 

0004 

FFFF 

I 

NOTE:  LOGICAL  CPU  NUMBERS  ABE  ASSIGNED 

IN  INCREMENTS  OF  2  TO  FACILITATE  INDEXING 

(OFFSETS)  INTO  LISTS  SUBSCRIPTED  BY 
LOGICAL  CPU  NUMBER.  ! 

0006 

4D05 

LD 

PRDS.LOG_CPU_ID,  #2 

0008 

0002* 

OOOA 

0002 

! 

SPECIFY  NUMBER  OF  VIRTUAL  PROCESSORS 
ASSOCIATED  HUB  PHYSICAL  CPU.  ! 

000C 

4D05 

LD 

PRDS. VP_NR,  *2 

000E 

0004* 

0010 

0002 

0012 

4D08 

CLR 

MEXT.BLOCK 

0014 

0000* 

0016 

4D08 

CLR 

NEXT_AVAIL_VP 

0018 

0000* 

00 1 A 

4D08 

CLR 

NEXT_EXT_VP 

00  1C 

0002* 

!  ESTABLISH  GATE  KEEPER  AS  SYSTEM  CALL 

TRAP  HANDLER  ! 

!  GET  BASE  OF  PROGRAM  STATUS  AREA  ! 
00  IE  7D15  LDCTL  R1,  PSAP 


!  ADD  SYSTEM  CALL  OFFSET  TO  PSA  BASS  ADDR  ! 
0020  0101  ADD  R1 ,  #SC  OFFSET 

0022  000C 

!  STORE  KERNEL  FCR  IN  PSA  1 
0024  0D15  LD  SRI,  VKERNEL  FCH 

0026  5000 

!  STORE  ADDRESS  OF  GATE  KEEPER  IN  PROGRAM 
STATUS  AREA  AS  SYSTEM  TRAP  HANDLER  ! 

0028  A911  INC  R 1 ,  *2 
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-1 


002A 

0D15 

LD 

SB1f  #GAT E_KEEPER_ENTHT 

002C 

0000* 

002E 

8018 

CLB 

R 1  !  NEXT_AVAIL_MMO  INDEX  1 

!  INITIALIZE  ALL  MHO  IMAGES  AS  AVAILABLE  ! 

SET_MM0_MAP: 

DO 

0030 

4C15 

LDB 

NEXT_AVAIL_NNO (fil) ,  # AVAILABLE 

0032 

0000* 

0034 

0000 

0036 

A910 

INC 

B1,  #1 

!  CHECK 

:  FOR  END  OF  TABLE  ! 

0038 

0801 

CP 

HI ,  # MAX  DBR  NR 

003A 

OOOA 

003C 

5E0E 

IF  BQ  THEN  EXIT  FBOH  SET  MMO  MAP  FI 

003E 

0044* 

0040 

5S08 

0042 

0046* 

0044 

B8F5 

OD 

!  CHEATS 

MEMORY  MANAGER  PROCESS  ! 

0046 

2103 

LD 

R3  ,  *  STACK.  BLOCK 

0048 

0001 

!  ALLOCATE  AND  INITIALIZE  KERNEL 

DOMAIN 

STACK  SEGMENT  ! 

004A 

5F00 

CALL 

MM. ALLOCATE  !R3:  #  OF  BLOCKS 

004C 

0000* 

RETURNS 

R2:  START  ADDR! 

004E 

A121 

LD 

HI,  R2 

0050 

2103 

LD 

S3,  #KERNEL_FCW 

0052 

5000 

0054 

7604 

LDA 

R4 ,  MM. ENTRY 

0056 

0000* 

0058 

6105 

LD 

R5 ,  XFFFP  1NSP1 

005A 

PFFF 

00  5C 

7606 

LDA 

R6,  PREEMPT.RET 

005E 

0000* 

0060 

93F1 

POSH 

OR  15,  B 1  ISAVE  STACK  ADDR! 

0062 

030F 

SOB 

R15,  *8 

0064 

0008 

0066 

1CF9 

LDM 

OR  1 5,  S3,  *4 

0068 

0303 

006A 

A1F0 

LD 

BO,  B15 

!  NOTE:  ABGLIST  FOB  CBE ATE. STACK  INCLOD ES 

KERNEL 

FCH ,  INITIAL  IC,  NSP,  AND  INITIAL 

return” 

POINT.  ! 

006C 

5F00 

CALL 

CREATE  STACK  !  (BO:  ABGOMENT  PTR 

006E 

0000* 

a  1 :  TOP  OF  STACK 
B2-B14:  INITIAL 
BEG. STATES  1 


0070  010P 
0072  0008 


iDD 


B 1 5,  *8  {OVERLAY  ARGUMENTS! 


!  ALLOCATE  MMU  IMAGE  ! 


0074 

5F00 

CALL 

ALLOCATE. MMU  1  RETURNS: 

0076 

0000* 

(RO:  DBR  #)  ! 

0078 

2101 

LD 

R1 ,  ♦SXACK.SBG  !  SEGMENT  NO. 

007A 

0001 

007C 

97F2 

POP 

R2 ,  RBI 5  ! GET  STACK  ADDR ! 

007E 

2103 

LD 

R3,  *0  !  WRITE  ATTRIBUTE  I 

0080 

0000 

!  SPECIFY  NUMBER  CF  BLOCKS.  COUNT  STARTS 

FROM 

ZERO.  (I.E.,1  BLOCK=0,  2=1,  ETC.)! 

0082 

2104 

LD 

R4,  # ST  ACK. BLOCK-*  1 

0084 

0000 

!  SAVE 

DBR  #  ! 

0086 

93F0 

POSH 

RR  15,  RO 

!  CREATE  MHO  ENTRY  FOB  MM  STACK  SEGMENT  ! 

0088 

5F00 

CALL 

UPDATE.MM O.IMAGE  !  (RO:  DBR  # 

008A 

0000* 

ai:  SEGMENT  « 

82:  SEG  ADDRESS 
R3 :  SEG  ATTRIBUTES 
R4:  SEG  LIMITS)  ! 

!  RESTORE  DBR  *  I 
008C  97P0  POP  RQ,  RR15 

!  GET  ADDRESS  OF  MMU  IMAGE  ! 

008E  5P00  CALL  GET  DBR  A DDR  !  (RO:  DBR  *) 

0090  0000* 

RETURNS: 

(R1:  DBR  ADDRESS)  ! 
!  PREPARE  VP  TABLE  ENTRIES  FOR  MM  1 


0092 

2102 

LD 

R2, 

•  2 

!  PRIORITY  ! 

0094 

0002 

0096 

2105 

LD 

85, 

•OFF 

!  PREEMPT  ! 

0098 

0000 

009A 

2106 

LD 

R6  , 

•  OFF 

!  KERNEL  PROCESS  ! 

009C 

0000 

!  UPDATE 

VPT 

! 

009E 

5F00 

CALL 

UPDATE  VP, 

.TABLE  !  (81 :  DBR 

00  AO 

01CA* 

R2:  PRIORITY 
R5:  PREEMPT  FLAG 
R6:  EXT.VP  FLAG) 
RETURNS: 

R9:  VP.ID  I 

!  INITIALIZE  MM.CPU.TBL  IN  DISTRIBUTED  MEMORY 
MANAGER  WITH  VP  ID  OF  MM  PROCESS  ! 

!  GET  LOGICAL  CPU  I  ! 

00A2  610A  LD  RIO,  PRDS.LOG  CPU.ID 
00A4  0002* 
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00  A6 

6PA9 

LD 

MM_CPU_TBL  (R10| ,  R9 

0  0  A8 

00004 

!  CREATE 

IDLE  PROCESS  l 

00  AA 

2103 

LO 

R3 ,  # ST AC K_ BLOCK 

00  AC 

0001 

00  AS 

5P00 

CALL 

HM_ALLOCATE  !R3:  f  OF  BLOCKS 

0060 

0000* 

RETURNS 

R2:  START  ADDR! 

00B2 

A121 

LD 

R1 ,  R2 

00B4 

2103 

LD 

S3,  #KERN EL_FCW 

00B6 

5000 

00B8 

7604 

LDA 

R4 ,  IDLE..ENTRI 

00BA 

0000* 

OOBC 

2105 

LD 

35,  ISFFPP  INSP1 

OOBE 

PPPP 

OOCO 

7606 

LDA 

R6 ,  PBEEMPT.BET 

00C2 

0000* 

00C4 

93F1 

POSH 

SR 15,  fil  ISAVE  STACK  ADDR 1 

00C6 

030  P 

SUB 

315,  #8 

00C8 

0008 

OOCA 

1CP9 

LDM 

iS 15,  S3,  *4 

OOCC 

0303 

OOCE 

A1P0 

LD 

BO,  R15 

!  INITIALIZE  IDLE  STACK  VALUES  ! 

OODO 

5P00 

CALL 

CREATE.STACK  !  (RO:  ARGUMENT  PTR 

00D2 

0000* 

R1 :  TOP  OF  STACK 
R2-R14:  INITIAL 

REG.  STATES  ! 

00D4 

010P 

ADD 

R1 5,  *8  1  OVERLAY  ARGUMENTS! 

00D6 

0008 

!  ALLOCATE  MMU  IMAGE  FOB  IDLE  PROCESS  ! 

00D8 

5  POO 

CALL 

ALLOCATE.MMU  1  RETURNS  BO:DBB  *  ! 

OODA 

0000* 

!  PREPARE 

IDLE  PROCESS  MMU  ENTRIES  ! 

00  DC 

2101 

LD 

R 1 ,  tSTACK.SEG  !  SEG  *  ! 

OODE 

0001 

OOE  0 

97P2 

POP 

R2,  SR  15  ! GET  STACK  ADDR! 

00E2 

2103 

LD 

33,  *0  J  MBITS  ATTRIBUTE 

00E4 

0000 

00E6 

2104 

LD 

R4 ,  #STACK_BL0CK>1  !  BLOCK  LIMITS 

00E8 

0000 

!  SAVE  DBR  #  l 

OOEA 

93P0 

PUSH 

SB  15,  RO 

I  CREATE 

MMU  IMAGE  ENTRT  ! 

00  EC 

5P00 

CALL 

UPDATB.MMU.IMAGE  !(R1:  SEGMENT* 

OOEE 

0000* 
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B2:  SEG  ADDRESS 
S3:  SEG  ATTRIBUTES 


H4:  SEG  LIMITS  )  i 


i  RESTORE 

DBR  *  ! 

OOFO 

97F0 

POP 

RO  ,  SR  1 5 

!  GET  MHO 

ADDRESS  ! 

00F2 

5F00 

CALL 

GET_DBR_ADDR  l 

(RO:  DBR  A) 

00F4 

0000* 

RETURNS 

(R1:  DBR  ADDRESS) 

(  PREPARE 

VPT  ENTRIES  FOR 

IDLE  PROCESS  ! 

OOF6 

2102 

LO 

R2,  10 

!  PRIORITY  ! 

OOFS 

0000 

OOFA 

2105 

LO 

R5,  AOFF 

!  PREEMPT  ! 

OOFC 

0000 

OOFE 

2106 

LD 

R6,  AOFF 

!  KERNEL  PROC  1 

0100 

0000 

!  CREATE 

VPT  ENTRIES  1 

0102 

5F00 

CALL 

UPDATE_VP_T ABLE 

!  (HI  :  DBR 

0104 

01CA* 

R2:  PRIORITY 

R4:  IDLE  FLAG 

R5;  PREEMPT 

36:  EXT  VP  FLAG) 
RETURNS: 

R9:  VP  ID  1 

!  ENTER  VP  ID  OF  IDLE  PROCESS  IN  PROS  ! 

0106 

6F09 

LD 

PR DS. IDLE  VP,  R9 

OIOS 

0006* 

!  INITIALIZE  IDLE  VP'S  1 

0 1 0A 

2102 

LD 

R2,  *1 

!  PRIORITY  ! 

010C 

0001 

0103 

2105 

LD 

R5 ,  AON 

!  PREEMPT  1 

01  10 

FFFF 

0112 

2106 

LD 

R6 ,  AON 

1  NON-KERNEL  PROC! 

0114 

FFFF 

01 16 

6100 

LD 

BO,  PRDS.VP_NR 

0118 

0004* 

!  INITIALIZE  VP  VALUES  t 

DO 

011A 

5F00 

CALL 

UPDATE_VP_T ABLE 

! (R1 :  DBR 

one 

Q1CA' 

R2:  PRIORITY 

R4:  IDLE  FLAG 

R5:  PREEMPT 

R6:  EXT_VP  FLAG) 
RETURNS: 

R9:  VP_ID  ! 

0  1 1E 

ABOO 

DEC 

RO,  A 1 

0120 

OBOO 

CP 

RO,  AO 

0122 

0000 

0124 

5E0E 

IF  SQ  ! ALL  VP'S  INITIALIZED!  THEN 

0126 

012C' 

0128 

5E08 

EXIT 
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0  12A 

012E» 

FI 

012C 

E8F6 

OD 

!  XNITILIZE  VPT  HEADEB  t 

I  GET  LOGICAL  CPO  MOMBER  i 

012E 

0130 

6102 

0002* 

LO 

B2,  PROS. L0G_CP0_ID 

0132 

0134 

0136 

4D05 

0000* 

0000 

LD 

VPT. LOCK,  #OFF 

0138 

013A 

013C 

4025 

0002* 

PPPP 

LO 

VPT.ROMHIHG_LISX  (R2)  ,  *HIL 

013E 

0140 

0142 

4D25 

0006* 

FPFP 

LO 

VPT.HEADY_LIST(B2)  ,  #HIL 

0144 

0146 

4D08 

000k* 

CLB 

VPT.FREE.LIST  ! HEAD  OF  HSG  LIST! 

; 

THREAD  VP'S 

BY  PRIORITY  AMO  SET  STATES  TO  READY  ! 

0148 

8D28 

CLB 

THREAD: 

DO 

R2  ! START  HITH  VP  *1! 

014A 

014C 

6100 

0002* 

LO 

R1 3,  PHDS . LOG_CPO_IO 

0  14E 
0150 

76D3 

0006* 

LOA 

R3, VPT. REAOY^LIST (R13) 

0152 

0154 

7604 

001C* 

LOA 

R4 , VPT. VP .HEXT_READI_VP 

0156 

0158 

7605 

0012* 

LDA 

R5, VPT. VP. PEI 

015A 

015C 

7606 

0014* 

LDA 

R6 , VPT. VP. STATE 

015E 

0160 

2107 

0001 

LD 

1  SAVE 

R7,«REAOY 

OBJ  10  1 

0162 

93F2 

POSH 

SR  15,  R2 

0164 

0166 

5F00 

0000* 

CALL 

LIST_INSEBT  !R2:  OBJ  10 

S3:  LIS T_HB ADAPTS  ADDS 
S4:  HEXT_OBJ  PTH 
H5:  PHIOHITT  PTE 


R6:  STATE  PTE 

R7:  STATE  ! 

!  RESTORE  OBJ  ID  ! 

0168 

97F2 

POP 

R2,  4R15 

0  16A 
016C 

0102 

0020 

ADD 

R2,  ISIZEOF  VP_TABLS 

0  16E 
0170 

0B02 

0100 

CP 

R2,  # (Nfi.VP  *  (SIZEOF  VP_TABLE) ) 

0172 

0174 

5E0E 

017A* 

IF  EQ 

THEM  EXIT  FROE  THREAD  FI 
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0176  5E08 
0178  017C* 

0 17A  E8E7  OD 

!  INITIALIZE  VP  HESS AGE  LIST  1 
t  NOTE:  ONLY  THE  THE SAD  FOB  THE  HESSAGE 
LIST  NEED  BE  CBEATEO  AS  ALL  HESSAGES 
ABB  INITIALLY  AVAILABLE  FOB  USE.  THE 
INITIAL  HESSAGE  VALUES  HEBE  CBEATBD 
FOR  CLABITY  ONLY  TO  SHOE  THAT  THE 
HESSAGES  HAVE  NO  USABLE  INITIAL  VALUE1 
0 17C  8D18  CLB  fil 

SSG_LST_INIT: 

!  NOTE:  El  BEPSESENTS  CUBBENT  ENTBY  IN 
HSG  LIST,  B2  BEPBESENTS  CUBBENT  POSITION 
IN  HSG.LIST  ENTBY,  AND  83  BEPBESENTS 
NEXT  ENTBY  IN  HSG.LIST.  ! 

DO 


017E 

A112 

LD 

R2,  B 1 

0180 

A123 

LD 

B3,  B2 

0182 

0103 

ADD 

H3,  tSIZEOF  HESSAGE 

0184 

0010 

FILL  HSG: 

DO 

0186 

4D25 

LD 

VPT.HSG_Q.HSG(B2)  ,  tINVALID 

0188 

0110* 

0 18A 

EEEE 

018C 

A921 

INC 

B2,  #2 

0  18E 

8B32 

CP 

B2,  B3 

0190 

5E0E 

IF  EQ 

THEN  EXIT  FBOH  FILL.HSG  FI 

0192 

0198* 

0194 

5E08 

0196 

019A* 

0198 

E8F6 

OD 

0  19A 

4D15 

LD 

VPT.HSG.Q.SENDEB (B1) ,  *NIL 

019C 

0120* 

0  19E 

FFFF 

01  AO 

A112 

LD 

B2 ,  HI 

01A2 

0101 

ADD 

Bl,  tSIZEOF  MSG  ..TABLE 

01A4 

0020 

01A6 

0B01 

CP 

R1 ,  tSIZEOF  HSG_TABLE*NB_VP 

01A8 

0100 

IF  EQ 

0 1 AA 

5E0E 

THEN 

01  AC 

01BC» 

01 AE 

4D25 

LD 

VPT.HSG_Q.NEXT_MSG (B2) ,  #NIL 

0 1  BO 

0122* 

01B2 

FFFF 

01B4 

5E08 

EXIT 

FBOH  HSG_LST_INII 

0 1B6 

01C2' 

0 1B8 

5E08 

ELSE 

0  1BA 

01C0' 

0 1 BC 

6F2 1 

LD 

VPT.HSG_Q.NEXT_HSG(B2) ,  Bl 
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0 1  BE  0122* 


FI 


01C0  E8DE  OD 

i  SET  LOGICAL  CPU  *  FOB  USE 
BY  ITC  GETHORK.  ! 

01C2  6100  LO  R13,  PBOS.LOG  CPU  ID 

01C4  0002* 

I  BOOTSTRAP  COUPLETS  ! 

i  START  SYSTEM  EXECUTION  AT  PREEMPT  ENTRY 
1  POINT  IN  ITC  GETHORK  PROCEDURE  ! 

01C6  5E08  JP  BOOTSTRAP  ENTRY 

01C8  0000* 

0 1CA  END  BOOTSTRAP 
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01 Cl  OPDATE_VP_TABLE  PROCEDURE 

I******************************** 

*  INITIALIZES  VPT  ENIBIES  * 

******************************** 

*  BEGISTEH  OSE:  * 

*  PARAMETERS:  * 


* 

B1 : 

DBR  ADDRESS 

* 

* 

B2: 

PRIORITY 

* 

* 

B5 : 

PREEMPT  FLAG 

* 

* 

B6 : 

EXTERNAL  VP  FLAG 

* 

* 

BETURNS: 

* 

* 

B9 : 

ASSIGNED  VP  ID 

* 

* 

LOCAL  VARIABLES: 

* 

* 

R7 : 

LOGICAL  CPO  * 

* 

* 

R8 : 

EXT_VP_LIST  OFFSET 

* 

* 

R9 : 

VPT  OFFSET 

* 

***************************** ***j 

ENTBY 

1 

SET  OFFSET  IN  VPT  FOR  NEXT 

ENTRY  I 

01CA 

6109 

LD 

R9«  NEXT_AVAIL_VP 

01CC 

0000 1 

0  ICE 

6P9 1 

LD 

VPT. VP. DBR (R9) ,  R1 

0  IDO 

0010* 

01D2 

6F92 

LD 

VPT. VP. PHI (B9) ,  R2 

01D4 

0012* 

01D6 

6F96 

LD 

VPT. VP. IDLE.FLAG (R9»  ,  R6 

01D8 

0016* 

01  DA 

6F95 

LD 

VPT.  VP.  PREEMPT  (H9)  , 

R5 

01  DC 

0018* 

01DE 

6107 

LD 

R7  ,  PRDS. LQG_CPU_ID 

0  ISO 

0002* 

01E2 

6F97 

LD 

VPT.VP. PHYS_PROCESSOR (R9)  , 

R7 

01E4 

00 1  A* 

01E6 

4D95 

LD 

VPT.VP. NEXT_READY_VP (R9)  , 

#NIL 

01E8 

001C* 

0  1 EA 

FFFF 

0  1EC 

4D95 

LD 

VPT.VP. MSG_LIST (R9) 

,  #NIL 

0  1EE 

00  IE* 

0 1 FO 

FFFF 

! 

CHECK 

EXTERNAL  VP  FLAG  ! 

0 1F2 

0S06 

CP 

R6 ,  *0N 

0  1F4 

FFFF 

IF  EQ 

'.EXTERNAL  VP! 

01F6 

SEOE 

THEN 

!  VP  IS  TC  VISIBLE  l 

01F8 

0210* 

0  1FA 

6108 

LD 

R8,  NEXT_EXT_VP 

0  1FC 

0002* 

!  INSERT  ENTRY  IN  EXTERNAL 

VP  LIST 

l 

0  1 FE 

6F89 

LD 

EXT_VP_LIST  (R8)  ,  R9 

0200 

0000* 

0202 

6F98 

LD 

VPT.VP.  £XT_ID(R9)  , 

R8 

0  204 

0020* 
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0206 

A981 

INC 

R8 ,  *2 

0208 

6F08 

LD 

NEXT_EXT_VP,  B8 

0  20A 

0002* 

020C 

5E08 

ELSE 

! VP  DOOND  TO  KERNEL  PROCESS! 

0  20E 

0216' 

0210 

4D0S 

LD 

VPT.VP.  EXT..ID,  #KIL 

0212 

0020* 

0214 

FFFP 

FI 

0216 

A19A 

LD 

RIO,  R9 

0218 

010A 

ADD 

RIO,  ISIZEOF  ?P_TABLE 

021A 

0020 

02  1C 

6F0A 

LD 

NEXT_AVAIL_VP,  RIO 

021E 

0000* 

0220 

9E08 

RET 

0222 

END  OPDATE_VP_TABLE 

END  BOOTSTRAP  LOADEB 
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Appendix  F 

LIBBABT  FUNCTION  LISTINGS 

Z8000 ASM  2.02 

IOC  OBJ  CODE  STMT  SOURCE  STATEMENT 

LIBB ABY_FUNCTION  MODULE 

SLISTON  $TTY 

CONSTANT 
KERNEL  FCH 
STACK  SEG  SIZE 
STACK  BASE 
STATUSJtEG  BLOCK 
INTERRUPT  FRAME 
INTERRUPT  BEG 
N  S  P 
NIL 


X3UUU 

*100 

STACK  SEG  SIZE-*  10 
STACK  SEG  SIZE-* 10 
STACK  BASE-4 
INTERBUPT  FBAME-34 
INTERRUPT  BEG-2 
*FFFF 
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SSECTION  LIB_PROC 
GLOBAL 


0000  LISr.IBSERT  PROCEDURE 

{ ************* ******************** 

*  INSERTS  OBJECTS  INTO  A  LIST  * 

*  BY  ORDER  OP  PRIORITY  AND  SETS  * 

*  ITS  STATE  * 

********************************* 

*  REGISTER  USE:  * 

*  PARAHETEBS:  * 


*  R2: 

OBJECT  ID 

* 

*  R3: 

HEAD.OF  LIST  PTR  ADDR 

* 

*  R4: 

NEXTJOBJ.PTR  ADDR 

* 

*  R5: 

PRIORITY_PTR  ADDR 

* 

*  R6: 

STATE  PTl  ADDR 

* 

*  R7: 

OBJECT  STATE 

* 

*  LOCAL  VARIABLES: 

* 

*  R8: 

HEAD_OF_LIST_PTR 

* 

*  R9: 

next”obj_ptr~ 

* 

*  RIO 

:  CORRENt”oBJ  PRIORITY 

* 

*  R 1 1 

:  NEXT  OBJ  PRIORITY 

* 

******************************** 

*2 

ENTRY 

2  GET  FIRST  OBJECT  IN  LIST  2 

0000 

2138 

LD 

R8f  3R3 

0002 

0B08 

CP 

R8,  *  NIL 

0004 

FFFF 

0006 

5E0E 

IF  EQ  2  LIST  IS  EMPTY!  THEN 

0008 

0018* 

2  PLACE  OBJ  AT  HEAD  OF  LIST  2 

000A 

2F32 

LD 

9R3,  R2 

OOOC 

7449 

LDA 

R9,  R4(R2) 

OOOE 

0200 

0010 

0D95 

LD 

9R9 ,  #NIL 

0012 

FFFF 

0014 

5E08 

ELSE 

0016 

005A* 

!  COMPARE  OBJ  PRI  WITH  LIST  HEAD  PRI 

0018 

715A 

LD 

RIO,  R5(R2)  2 OBJ 

PRI  2 

00  1 A 

0200 

00  1C 

715B 

LD 

R  1 1 ,  R5  (R8)  2  HEAD 

PRI  2 

001E 

0800 

0020 

8BBA 

CP 

RIO,  R11 

0022 

5E02 

IF  GT 

2 OBJ  PRI>HEAD  PRI2  THEN 

0024 

0030' 

0026 

2F32 

LD 

9R3 ,  R2  2 PCJT  AT 

FRONT2 

0028 

7348 

LD 

R4 (R2) ,  R8 

002A 

0200 

002C 

5E08 

ELSE  1 

INSERT  IN  BODY  OF  LIST  2 

002E 

005A’ 

SEARCH  LIST: 
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DO 

0030 

0B08 

CP 

R8,  #  NIL 

0032 

PPPP 

0034 

5E0E 

IP  EQ 

! END  OP  LIST!  THEN 

0036 

00  3C' 

0038 

5E08 

EXIT 

PBOE  SEABCH.LIST 

003* 

0052’ 

PI 

003C 

715B 

LD 

fill,  85  (BB)  !  GET 

NEXT  PBI! 

003E 

0800 

0040 

8BBA 

CP 

BIO,  fill 

0042 

5E02 

IP  GT 

! COB  BENT  PBI>NEXT  PBI! 

THEN 

0044 

004A' 

0046 

5E08 

EXIT 

PBOE  SEABCH.LIST 

0048 

0052' 

PI 

!  GET 

NEXT  OBJ  ! 

004A 

A189 

LD 

B9 ,  B8 

004C 

7148 

LD 

B8,  B4(B9) 

004E 

0900 

0050 

E8EP 

OD  i 

END  SEABCH_LIST  i 

!  INSERT  IN  LIST  I 

0052 

7348 

LD 

B4(B2),  B8 

0054 

0200 

0056 

7342 

LD 

B4(B9),  B2 

0058 

0900 

PI 

PI 

1  SET  OBJECT'S  STATE  ! 

005A 

7367 

LD 

B6  (B2) ,  B7 

005C 

0200 

005E 

9E08 

BET 

0060 

END  LIST.INSEBT 
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0060  CREATE_STACK  PROCEDUB  E 

J ************  *******  ************* 

*  INITIALIZES  KERNEL  STACK  * 

*  SEGMENT  FOR  PROCESSES  * 

******************************** 

*  REGISTER  OSE:  * 

*  PARAMETERS:  * 

*  RO:  ARGOHENT  POINTER  * 

*  (INCLUDES: FCH , IC, NSP,  AND  * 

*  RETURN  POINT.  SEE  LOCAL  * 

*  VARIABLES  BELOW.)  * 

*  R1:  TOP  OF  STACK  * 

*  R2-R14:  INITIAL  REGISTER  * 

*  STATES.  (NOTE:  IN  DEMO,  HO* 

*  SPECIFIC  INITIAL  REGISTER  * 


*  VALUES  ARE  SET,  EXCEPT  R13* 


*  (USER  ID)  FOR  USER  PRO-  * 

*  CESSES.)  * 

******************************** 

*  LOCAL  VARIABLES  * 

*  (FROM  ARGUMENTS  STORED  ON  * 

*  STACK.)  * 

*  R3:  FCW  * 

*  R4  :  PROCESS  ENTRY  POINT  (IC)  * 

*  R5:  NSP  * 

*  R6:  PREEMPT  RETURN  POINT  * 


******************************** I 


ENTRY 

0060 

93F0 

PUSH 

3R 15,  RO  ISAVE  ARGUMENT  PTR! 

0062 

ADFO 

EX 

RO,  R15  ISAVE  SPI 

0064 

34  IF 

L  DA 

R1 5,  R1  (#INTERRUPT_REG) 

0066 

OOCA 

0068 

1CF9 

LDM 

IRIS,  R 1,  #16  ! INITIAL  REG.  VALUES 

006A 

Q1QF 

!  NOTE: 

ONLY  REGISTERS  R2-R14  MAY  CONTAIN 

INITIALIZATION  VALUES  ! 

006C 

A10F 

LD 

R15,  RO  IRESTORE  SP! 

006E 

97F0 

POP 

RO,  3R1 5  IRESTORE  ARGUMENT  PTR I 

0070 

A1FE 

LD 

R 1 4,  R15  ISAVE  CALLER  RETURN  POINT! 

0072 

A10F 

LD 

R15,  RO  IGET  ARGUMENT  PTR1 

0074 

1CF 1 

LDM 

R3,  ifi 1 5,  *4  1L0AD  ARGUMENTS! 

0076 

0303 

0078 

34  IF 

LDA 

R 1 5,  R1  (#INTERRUPT_FR AME) 

007A 

OOEC 

007C 

1CF9 

LDM 

3R 15,  R3,  #2  UNIT  IRET  FRAME! 

007E 

0301 

0080 

34  IF 

LDA 

R15,  R1(#N_S_P) 

0082 

00C8 

0084 

2FF5 

LD 

3R 15,  R5  ! SET  NSP! 

0086 

030F 

SUB 

R15,  #2 

0088 

000  2 

008A 

2FF6 

LD 

3R15,  R6  (PREEMPT  RET  POINT! 

008C 

3418 

LDA 

R8  ,  R1  (#STACK_BASE) 
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008E  OOFO 


!  INITIALIZE  STATUS  REGISTER  BLOCK  I 
0090  2100  LO  RO,  iKERNEL  FCM 

0092  5000 

0094  1C89  LOR  988,  R15,  *2  1SAVE  SP  6  FCBi 

0096  0F01 

0098  A1EF  LO  R15,  R14  I  RESTORE  RETURN  POINT! 

009A  9E08  RET 

009C  END  CREATE  STACK 

END  LIBRARY  FUNCTION 
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INNER  TRAFFIC  CO HT ROLLER  LISIIR6S 
Z8000ASM  2.02 

LOC  OBJ  CODE  ST ST  SOURCE  STATEMENT 

INNBR_TRAFFIC_CONTROL  MODULE 
SLI5T0N  $TTT 
J**1.  GETHORK: 

A.  NORMAL  ENTRY  DOES  NOT  SAVE  REGISTERS. 

(  THIS  IS  A  FUNCTION  OF  THE  GATEKEEPER  ). 

B.  R14  IS  AN  INPUT  PARAMETER  TO  GET WORK  THAT 
SIMULATES  INFO  THAT  HILL  EVENTUALLY  BE  ON 
THE  MMU  HARDHARE.  THIS  REGISTER  MUST  BE 
ESTABLISHED  AS  A  DBS  BY  ANY  PROCEDURE 
INVOKING  G2TW0RK. 

C.  THE  PREEMPT  INTERRUPT  ENTRY  HANDLER  DOES 
NOT  USE  THE  GATEKEEPER  AND  MUST  PERFORM 
FUNCTIONS  NORMALLY  ACCOMPLISHED  BY  IT 
PRIOR  TO  NORMAL  ENTRY  AND  EXIT. 

(  SAVE/RESTORE:  REGS,  NSP;  UNLOCK  VPT,  TEST  INT) 

2.  GENERAL: 

A.  ALL  VIOLATIONS  OF  VIRTUAL  MACHINE  INSTRUCTIONS 
ARE  CONSIDERED  ERROR  CONDITIONS  AND  HILL  RETURN 
SYSTEM  TO  THE  MONITOR  WITH  AN  EBROR  CODE  IN  RO 
AND  THE  PC  VALUE  IN  R1 . 

3.  ITC  PROCEDURES  CALLING  GETHORK  PASS  DBR 
(REGISTER  E14)  AND  LOGICAL  CPU  NUMBER 
(REGISTER  R13)  AS  INPUT  PARAMETERS. 

(INCLUDES:  SIGNAL,  HAIT,  SHAP  VDBR, 
PHYS_PREEMPT_HANDLEB,  AND  IDLE) .  J 

CONSTANT 

1  ********** 

U  L  0 

m“l  EM  :=  1 

s'l'er  :=  2 

B~L~2  :*  3 

M  L  0  :*  4 

S~N~A  :*  5 

V~i"e  ;*  6 

a'u'  :*  7 


ERROR  CODES  **********  i 
1  UNAUTHORIZED  LOCK  ! 
i  MESSAGE  LIST  EMPTY  ! 

1  MESSAGE  LIST  EBROR  ! 

1  READY  LIST  EMPTY  ! 

1  MESSAGE  LIST  OVERFLOH  ! 
i  SHAP  NOT  ALLOHBD  ! 

1  VP  INDEX  EREOfi  ! 

!  MMU  UNAVAILABLE  I 
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|  ********  SYSTEM 
NR  SDR  :* 

NR  CPO 

NR  7P  :* 

HR  A7AIL  7P  :» 

MAX  DBR  HR  :« 

STACK  SEG  :* 

PROS  SEG  := 

STACK  SEG  SIZE  :* 


PARAMETERS  ********  ! 
64  i LONG  WORDS I 
2 

HR  CPtl*4 
NR~CPU*2 
10  IPER  CPO! 

1 

0 

*100 


1  *****  OFFSETS  IN 
STACK  BASE  :* 

STATU S_HEG_BLOCK :a 
INTER RUPT_F RAM E  :* 

INTERRUPT  REG  :* 

N  S  P  :  = 

F_C_B  := 

ON  :=  *FFFF 

OFF  : =  0 

RUNNING  :  =  0 
READY  :*  1 
BAITING  :=  2 
HIL  :=  SFFFF 

IN7ALID  :=  *EEEE 
HONITOR  :»  *A900  1  HBUG  ENTRY  ! 

KERNEL  FCB  :*  *5000 
A7AILABLE  :=  0 
ALLOCATED  :*  *FF 


STACK  SEG  *****  1 
STACK  SEG  SIZE-*10 
ST ACK_SEG_SIZE- *10 
STACK  BASE- 4 
INTERRUPT  FRAHE- 34 
INTERRUPT  REG-2 
STACK  SEG  SIZE-XE 


TYPE 

MESSAGE  ARRAY  £  16  BYTE] 

ADDRESS  WORD 

VP  INDEX  INTEGER 

MSG_INDEX  INTEGER 

SEG  DESC  REG  RECORD 

c 

BASE  ADDRESS 

ATTRIBUTES  BYTE 

LIMITS  BYTE 

] 

MMU  ARRAY£  NR_SDR  SEG.DESC.RSG ] 


MSG  TABLE  RECORD 


[  MSG 
SENDER 
NEXT  MSG 
FILLER 

3 


MESSAGE 
YP.INDEX 
MSG  INDEX 
ARRAY  £6,  BORD ] 
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0000 

0210 

0000 

0*00 
0  AOi 


VP  TABLE  RECORD 


t 


DBB 
PBI 
STATE 
IDLE  FLAG 
PREEMPT 


ADDBESS 


HOBD 
if  OBD 
BOBD 
HOBD 


pars  pbocessob  hoed 

NEXT“sEADY  VP  VP  INDEX 
MSG  LIST 


EXT  ID 
FILLER. 


MSG  INDEX 
HOBD 

ABBAX[  7, 


HOBD  ] 


EXTEBNAL 

LIST  INSEBT 


PROCEDURE 


GLOBAL 

BOOTSTBAP.ENTBX  LABEL 
SSECTION  ITC  DATA 


VPT  BECOBD 

£  LOCK  HOBD 

RUNNING  LIST  ABBAX[ NR  CPU  HOBD] 

BEADY  LIST  ASSAY [ NB  CPU  HOBD] 
PSEE.LIST  MSG  INDEX 

VIBT_INT_VEC  ABBAY[ 1,  ADDBESS] 
FILLEB_2  HOBD 

VP  ABBAY  [NRJTP,  VP JT ABLE] 

MSG  Q  ABBAY  £  MB  VP,  MSG  TABLE] 

] 

EXT_VP_LISI  ABBAY[NB_AVAIL_VP  HOBD] 
SSECTION  MHO  DATA 


MHO  IMAGE  BECOBD 

C 

MMO  STBOCTOBE  ABBAY[  MAX  DBB  NB  MHO] 

] 

NEXT  AVAIL  SHU  ABBA  Y[  MAX  DBB  NB  BYTE] 

PBDS  RECORD 

C  PHYS_CPU_ID  HOBD 
LOG_CPO_ID  INTEGER 
VP  NB  HOBD 

IDLE  VP  VP  INDEX] 


337  - 


IS EC? ION  ITC_INT_PROC 
INTERNAL 

0000  GETWORK  PROCEDURE 

]  **********41** ****************** 

*  SWAPS  VIRTUAL  PROCESSORS  * 

*  ON  PHYSICAL  PROCESSOR.  * 

******************************* 

*  PARAMETERS:  * 

*  R13:  LOGICAL  CPU  *  * 

*  REGISTER  USE:  * 

*  STATUS  REGISTERS  * 

*  R 14:  DBR  (SIMULATION)  * 

*  R15:  STAC K_POINT ER  * 

*  LOCAL  VARIABLES:  * 

*  R1:  READY  VP  (NER)  * 

*  R2:  CURRENT  VP  (OLD)  * 

*  R3:  FLAG  CONTROL  WORD  * 

*  R4:  STACK  SEG  BASE  ADDR  * 

*  R5 :  STATUS  REG  BLOCK  ADDR  * 

*  R6:  NORMAL  STACK  POINTER  * 

*******************************{ 

ENTRY 

!  GET  STACK  BASE  ! 

0000  31E4  LD  H4,  R14 (#STACK_SEG*4) 

0002  0004 

0004  3445  LDA  R5,  R4  (#ST ATUS  REG  BLOCK) 

0006  00F0 

!  *  *  SAVE  SP  *  *  1 
0008  2F5F  LD  3RS,  R15 

!  *  *  SAVE  FCH  *  *  1 
000A  7D32  LDCTL  R3,  FCW 

000C  3343  LD  R4 (#F_C_H) ,  R3 

000E  00F2 

BOOTSTRAP_ENTRY :  !  GLOBAL  LABEL  ! 

J  GET  READY_VP  LIST  ! 

0010  61D1  LD  HI,  VPT. READY  LIST(R13) 

0012  0006* 

SELECT_VP: 

DO  !  UNTIL  ELGIBLE  READY.VP  FOUND  ! 

0014  4D1 1  CP  VPT. VP. IDLE  FLAG  (R 1)  ,  *ON 

0016  0016' 

OC 18  FFFF 

001 A  5E0E  IF  EQ  !  VP  IS  IDLE  !  THEN 

001C  0030* 

00 IE  4D11  CP  VPT. VP. PREEMPT(RI) ,  #ON 

0020  0018* 

0022  FFFF 

0024  5E0E  IF  EQ  I  PREEMPT  INTERRUPT  IS  ON  !  THEN 

0026  00 2C' 

0028  5B08  EXIT  FROM  SELECT_VP 

002A  003C* 
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002C  5E08 
002B  0034* 
0030  5E08 
0032  003C* 


0034  6113 
0036  001C' 
0038  A131 
003&  E8EC 


ELSE  t  VP  NOT  IDLE  ! 
EXIT  FROM  SELECT  VP 


!  GET  NEXT  READY  VP  ! 

LD  R3 ,  VPT. VP.NEXT_READY_VP(R1) 

LD  R1 ,  R3 
OD 

!  NOTE:  THE  READY_LIST  HILL  NEVER  BE  EMPTY  SINCE 
THE  IDLE  VP,  HHICH  IS  THE  LOHEST  PRI  VP, 

HILL  NEVER  BE  REMOVED  FROM  THE  LIST. 

IT  HILL  RON  ONLY  IF  ALL  OTHER  READY  VP*S  ARE 
IDLING  OR  IF  THERE  ARE  NO  OTHER  VP*S  ON 
THE  READY  LIST.  ONCE  SCHEDOLED,  IT 
HILL  RON  ONTIL  RECEIVING  A  HD  HE  INTERROPT.  1 

!  NOTE:  R 14  IS  USED  AS  DBR  HERE.  HHEN  MHO 

IS  AVAILABLE  THIS  SERIES  OF  SAVE  AND  LOAD 
INSTRUCTIONS  HILL  BE  REPLACED  BY  SPECIAL  I/O 
INSTRUCTIONS  TO  THE  HMU.  ! 

!  PLACE  NEW  VP  IN  RUNNING  STATE  ! 


» 

003C 

4D15 

LD 

VPT. VP. STATE (R1) ,  tRUNNING 

■ 

003E 

0014* 

0040 

0000 

i 

0042 

6FD1 

LD 

VPT.RUNNING_LIST (R13)  ,  R1 

0044 

0002* 

: 

j  * 

*  SHAP  DBR  *  *  ! 

» 

0046 

61  IE 

LD 

HI  4,  VPT. VP. DBR  (R1) 

0048 

0010* 

!  LOAD  NEH  VP  SP  i 

V 

004A 

31E4 

LD 

R4 ,  R14  (#STACK_SEG*4) 

004C 

0004 

004E 

3445 

LD  A 

R5,  R4  (#STAXUS_REG_BLOCK) 

0050 

00F0 

0052 

215F 

LD 

R15,  a)R5 

i 

•  i 

V 

!  * 

*  LOAD  NEH  FCH  *  *  l 

0054 

3143 

LD 

R3,  R4(#F_C_H) 

0056 

00F2 

0058 

7D3A 

LDCTL  FCH ,  R3 

005A 

9E08 

RET 

005C 

END  GETHORK 
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005C  ENTEB_MSG_LIST  PROCEDURE 

t  ********************************* 

*  INSERTS  POINTER  TO  MESSAGE  * 

*  PROM  CORRENT_VP  TO  SIGNAL£D_7P* 

*  IN  PIPO  MSG_LIST  * 

********************* ************ 

*  REGISTER  USE:  * 

*  PARAMETERS:  * 

*  R8  (R9) :  MSG  (INPUT)  * 

*  Hi:  SIGNALED  VP  (INPUT)  * 

*  R13:  LOGICAL  CPU  NUMBER  * 

*  LOCAL  VARIABLES:  * 

*  R2:  CURRENT_VP  * 

*  R3:  pirst_f5ee_msg  * 

*  R4 :  NEXT  FREE  IsG  • 

*  R5:  NEXT_Q  MSG  * 

*  R6:  PRESENT_Q_MSG  * 

*********************************  I 

ENTRY 

005C  61D2  LD  R2f  VPT. RUNNING  LIST  (R 13) 

005E  0002* 

J  GET  FIRST  MSG  FROM  FREE_LIST  ! 

0060  6103  LD  R3,  VPT. FREE-LIST 
0062  000A' 

]  *  *  *  *  DEBUG  *  *  *  *  ! 

0064  0B03  CP  R3,  ANIL 

0066  FFFF 

0068  5E0E  IF  EQ  THEN 

006A  0078* 

006C  7601  LD A  R1,  $ 

006E  006C* 

0070  2100  LD  RO,  #M  L  01  MESSAGE  LIST  OVERFLOW  ! 

0072  0004 

0074  5F00  CALL  MONITOR 

0076  A900 

FI 

!  *  *  *  END  DEBUG  *  *  *  ! 

0078  6134  LD  R4,  VPT. MSG_Q. NEXT_MSG (R3) 

007A  0122' 

007C  6F04  LD  VPT. FREE  LIST,  R4 
007E  000A' 

I  INSERT  MESSAGE  LIST  INFORMATION  ! 

0080  763A  LD  A  RIO, VPT.  MSG  Q.MSG(R3) 

0082  0110' 

0084  2107  LD  R7,*SIZEOF  MESSAGE 

0086  0010 

0088  BA8 1  LDIRB  »R10,dR8,R7 

008A  07 AO 

008C  6F32  LD  VPT. MSG  Q  .  SENDER  (R3)  ,  R2 
008E  0120* 
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!  INSERT  MSG  IN  MSG  LIST  ! 


0090 

6115 

LD  R5, 

VPT.  VP.MSG_LISI(B1) 

0092 

00  IE' 

0094 

0B05 

CP  R5, 

ANIL 

0096 

FFFF 

0098 

5E0E 

IF  EQ 

!  MSG  LIST  IS  EMPTI  !  THEN 

009A 

OOA4  • 

!  INSERT  MSG  AT  TOP  OF  LIST  ! 

009C 

6F13 

LD  VPT 

. VP.MSG_LIST(R1) ,  S3 

009E 

00  IE' 

00  AO 

5E08 

ELSE  ! 

INSERT  nSG  IN  LIST  1 

00  A2 

OOBC* 

MSG  Q  SEARCH: 

DO  WHILE  NOT  END  OF  LIST  1 

00A4 

0B05 

CP 

R5 ,  ANIL 

00A6 

FPFF 

00A8 

5E0E 

IF  EQ 

!  END  OF  LIST  !  THEN 

00A& 

OOBO* 

OOAC 

5E08 

EXIT 

FROM  MSG_Q_SEABCH 

00  AE 

00B8  * 

FI 

!  GET 

NEXT  LINK  ! 

OOBO 

A156 

LD 

R6 ,  E5 

00B2 

6165 

LD 

R5,  VPT. MSG_Q . NEXT_MSG (R6) 

00B4 

0122* 

00B6 

E8F6 

OD 

!  INSERT  MSG  IN  LIST  ! 

00B8 

6F63 

LD 

7PT.MSG_Q.NEXT_MSG(R6) ,  R3 

OOBA 

0122* 

FI 

OOBC 

6F35 

LD 

yPT.MSG_Q.NEXT_MSG(R3)  ,  R5 

OOBE 

0122' 

OOCO 

9E08 

RET 

00C2 

END  ENTER_ 

MSG_LIST 
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00C2 


GET.FIR  ST.MSG  PROCEDURE 

|  *********************************** 

*  REMOVES  MSG  FROM  MSG  LIST  * 

*  AND  PLACES  ON  FREE  LIST.  * 

*  RETURNS  SENDER'S  MSG  AMD  * 

*  VP  ID  * 

*********************************** 

♦REGISTER  USE:  ♦ 

*  PARAMETERS:  ♦ 

*  R0(R9):  MSG  POINTER  (INPOT)  * 

*  R13:  LOGICAL  CPU  NUMBER  (INPUT)* 

*  HI :  SENDER  VP  (RETURNED)  ♦ 

*  LOCAL  VARIABLES  ♦ 

*  H2:  CURRENT.VP  * 

*  R3:  FIRST  MSG  ♦ 

*  R»:  NEXT  MSG  * 

*  R5:  NEXT  FREE  MSG  * 

*  R6 :  PRESENT.FREE.MSG  * 

***********************************1 
ENTRY 

00C2  61D2  LD  R2,  VPT. RUNNING  LIST(R13) 

00C4  0002* 

!  REMOVE  FIRST  MSG  FROM  MSG.LIST  ! 

00C6  6123  LD  R3,  VPT. VP. MSG  LIST(R2) 

OOC8  00 IE* 

1  *  *  *  *  DEBUG  *  *  *  *  ! 

OOCA  0B03  CP  R3,  ANIL 

OOCC  FFFF 

OOCE  5E0E  IF  EQ  THEN 

OODO  OODE* 

00D2  2100  LD  RO,  »H_L  EH  i  MSG  LIST  EMPTY  ! 

00D4  0001 

00D6  7601  LDA  B1,  $ 

00D8  00 D6  * 

OODA  5F00  CALL  MONITOR 

OODC  A900 


FI 

!  *  *  *  END  DEBUG  *  *  ♦  I 


OODE 

6134 

LD 

R4,  VPT.HSG_Q.NEXT_MSG  (R3) 

OOEO 

0122* 

00E2 

6F24 

LD 

VPT. VP. MSG .LIST (R2) ,  R4 

00B4 

001E* 

!  INSERT  MESSAGE  IN  FREE  LIST 

00E6 

6105 

LD 

R5#  VPT. FREE.LIST 

00E8 

OOOA* 

OOEA 

0B05 

CP 

R5 ,  ANIL 

OOEC 

FFFF 

00  EE 

5E0E 

IF  BQ 

!  FREE.LIST  IS  EMPTY  I  THEN 

OOFO 

0100* 

t  INSERT  AT  TOP  OF  LIST  ! 

00F2 

6F03 

LD 

VPT. FREE.LIST*  R3 

00F4 

OOOA* 

00F6 

4035 

LD 

VPT . HSG_Q. NEXT_HSG (S3)  (  #NIL 

00F8 

0122* 

00FA 

FFFF 

OOFC 

5E08 

ELSE  1 

INSERT  IN  LIST  1 

OOFE 

011C' 

FEES  Q  SEARCH: 

DO 

0100 

0B05 

CP 

H5,  ANIL 

0102 

FFFF 

0104 

5E0E 

IF  EQ 

!  END  OF  LIST  !  THEN 

0106 

010C' 

0108 

5E08 

EXIT 

FfiOH  FREE_Q_SEABCH 

0 10A 

0114* 

FI 

!  GET 

NEXT  HSG  ! 

010C 

A156 

LD 

B6f  R5 

0  10E 

6165 

LD 

R5#  7PT. HSG_Q . NEXT_NSG (B6> 

0110 

0122* 

0112 

E8P6 

OD 

!  INSERT 

IN  LIST  ! 

0114 

6F6  3 

LD 

VPT.HSG_Q.NEXTJISG  (B6J  ,  B3 

01 16 

0122* 

0118 

6F35 

LD 

FPT. HSG_Q. NEXT_NSG (R3)  ,  R5 

01  U 

0122* 

FI 

!  GET  HE 

f SAGE  INFORHATION: 

(BETH BUS  B1:  SENDING.VP)  ! 

one 

6131 

LD 

HI,  VPT.  HSG_Q.  SENDER  (R3) 

01  IE 

0120' 

0120 

76  3A 

LDA 

RIO  y  VPT. NSG_Q. HSG (R3| 

0122 

0110* 

0124 

2107 

LD 

R7#  #SI aeof  hessage 

0126 

0010 

0128 

BAA1 

LDIBB 

aR8,aaio,a7 

012A 

0780 

012C 

9E08 

BET 

0 12E 

END  GET_FIRST_HSG 
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I  *  *  I  HUES  TRAFFIC  CONTROL  ERIE I  POINTS  *  »  ! 

!  NOTE:  ALL  INTERRUPTS  RUST  BE  BASKED  WHENEVER 
THE  VPT  IS  LOCKED.  THIS  IS  TO  PREVENT  AN 
SHBRACE  FRON  OCCURRING  SHOULD  AN  INTERRUPT 
OCCUR  WHILE  THE  VPT  IS  LOCKED.  1 

GLOBAL 

SSECTION  ITC_GLB_PROC 

PREEHPT.RET  LABEL 
KERNEL  EXIT  LABEL 

0000  CREATE_INT_VEC  PROCEDURE 

I  ******************************** 

*  CREATES  ENTRY  IN  VIRTUAL  INI-* 

*  ERRUPT  VECTOR  WITH  ADDRESS  * 

*  OF  THE  VIRTUAL  INTERRUPT  HAN-* 

*  DLER.  * 

*  PARAHBTERS:  * 

*  R1:  VIRTUAL  INTERRUPT  *  * 

*  R2:  INTERRUPT  HANDLER  ADDR  * 

********************************  1 

ENTRY 

!  COBPUTE  OFFSET  IN  VIRTUAL 
INTERRUPT  VECTOR  1 

0000  1900  HULT  RRO,  ASIZBOF  ADDRESS 

0002  0002 

!  SAVE  ADDRESS  OF  VIRTUAL  INTERRUPT 
HANDLER  IN  INTERRUPT  VECTOR  ! 

0004  6F12  LD  VPT.VIRT  INT  VEC(RI),  R2 

0006  OOOC* 

0008  9E08  RET 

000A  END  CREATE  INT  VEC 
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0004 


OOOA  7601 
OOOC  0000* 


OOOE  8101 
0010  9E08 
0012 


GET  DBR_ADDR  PROCEDURE 

1  ******************************** 

*  CALCULATES  DBB  ADDRESS  PROM  * 

*  OBB  NUMBER  * 

******************************** 


*  REGISTER  USE: 

*  PARAMETERS: 

*  RO:  DBR  • 

*  RETURNS: 

*  HI :  DBR  ADDRESS 


1 


ENTRY 

!  GET  BASE  ADDRESS  OF  MHO  IMAGE  ! 
LDA  HI,  MHO  IMAGE 


!  ADD  DBR  HANDLE  (OFFSET)  TO  NHU  BASE 
ADDRESS  TO  OBTAIN  DBB  ADDRESS  I 
ADD  B1,  BO 

BET 

END  GETJJBR  ADDS 
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0012 


PBOCEDOBE 


ALLOCATE.HMU 
|************: 

*  ALLOCATES  NEXT  AVAILABLE  MHU  * 

*  I BAGS  AND  CB SATES  PBDS  ENTBT  * 
******************************** 

*  BEGISTEB  USB:  * 

*  BETOBNS:  * 

*  RO:  DBS  #  * 

*  LOCAL  VARIABLES:  * 

*  Bis  SEGMENT  *  * 

*  B2 :  PBDS  ADDRESS  * 

*  B3:  PROS  ATTRIBUTES  * 

*  R4:  PROS  LIMITS  * 

************** ******************1 
ENT  RT 

!  GET  NEXT  AVAILABLE  DBB  *  ! 

0012  8D08  CLR  RO 

0014  8D18  CLB  SI 

I  NOTE:  THE  FOLLOHING  IS  A  SAFE  SEQUENCE 
AS  NEXT_AVAIL_MMO  AND  MHO  ABE  CPO  LOCAL! 

GET  DBB: 

DO 

0016  4C1 1  CPB  NEXT  AVAIL  HMO  (R1) ,  # AVAILABLE 

0018  OAOO* 

001 A  0000 

IF  SQ  ! HMO  ENTBT  IS  AVAILABLE! 

00 1C  SEOE  THEN 

00 IE  Q02E* 

0020  4C15  LOB  NEXT.AVAIL.MMO (B1) ,  4 ALLOCATED 

0022  OAOO* 

0024  FFFF 

0026  5 EOS  EXIT  FBOM  GET.DBR 

0028  004A* 

002A  5B08  ELSE  ! CURRENT  ENTBT  IS  ALLOCATED! 

002C  0048* 

002E  A910  INC  R1,  *1 

0030  0100  ADD  R0V  iSIZEOF  MHO 

0032  0100 

|  *  *  *  *  DEBOG  *  *  *  *  ! 

0034  0B01  CP  B1,  #MAX_DBB_NB 

0036  OOOA 

0038  5E0E  IF  EQ  THEN 

003A  0048* 

003C  2100  LD  BO,  *H_0  IMMO  UNAVAILABLE! 

003E  0007 

0040  7601  LDA  B1 #  S 

0042  0040* 

0044  5F00  CALL  HONITOB 

0046  A 900 

FI 

!  *  *  *  END  DEBUG  *  *  *  1 
FI 

0048  E8E6  OD 
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004  A 

2101 

LD 

ait 

#PHDS_SEG 

1  SEGMENT  NO.  t 

004C 

0000 

004E 

7602 

LDA 

H2 , 

PHDS 

1  PHDS  , 

ADDR  ! 

0050 

OAOA* 

0052 

2103 

LD 

H3, 

*1  1  BEAD 

ATTR  ! 

0054 

0001 

0056 

2104 

LD 

H4, 

*(  (SIZEOF 

PROS) - 1)  /256 

0058 

0000 

!  PHDS 

LIMITS 

1 

!  CHEATS 

PHDS 

ENTRY  IN  MMO  IMAGE  1 

005A 

5POO 

CALL 

U  PD  ATE  _M  MU  _I  M AGE  !  (HI : 

SEGMENT  * 

005C 

0060' 

R2: 

SEG  ADDRESS 

R3: 

ATTRIBUTES 

R4 : 

SEG  LIMITS)  ! 

005B 

9E08 

BBT 

0060 

EHD  ALLOCATE JIHO 
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0060 


PBOCEDUBB 


OPD ATE  M NO  IMAGE 
t  ****************1 

*  CBBATES  SEGMENT  DESCBIPTOB 

*  ENTRY  IN  MHO  IMAGE 
******************************* 

*  BEGISTEB  OSE: 


PABAMETEBS: 

BO: 

DBB  * 

B1: 

SEGMEMT 

# 

B2: 

SEGMEBT 

AODBESS 

B3: 

SEGMEMT 

ATTBI BOTES 

B4: 

SEGMEMT 

LIMITS 

LOCAL 

7ABIABLES: 

BIO: 

MMO  BASE  AODBESS 

H13: 

OFFSET 

7ABIABLE 

******************************** I 

EMTBT 


0060 

210A 

LD 

BIO,  *MMU  IMAGE  !  MMO  BASE  ADDBSSS  ! 

0062 

0000* 

0064 

810A 

ADD 

BIO,  BO 

0066 

210D 

LD 

B 13 ,  iSIZEOF  S EG _D ESC_BEG 

0068 

0004 

006A 

991C 

HOLT 

BB12,  B 1  f  COMPOTE  SEG_ 

DESC  OFFSET  1 

006C 

810A 

ADD 

RIO,  R13  1ADD  OFFSET  TO 

BASE  ADDBSSS! 

I  IMSEBT  DESCBIPTOB  DATA  ! 

006E 

2FA2 

LD 

SB1 0 ,  B2 

0070 

A9A1 

INC 

BIO,  *2 

0072 

0DA8 

CLB 

3810 

0074 

2EAC 

LDB 

3810,  BL4 

0076 

A9A0 

INC 

BIO,  *1 

0078 

20  AC 

LDB 

BL4 ,  SB 10 

007A 

OAOB 

CPB 

BL3,  *1(2)00001000  !  EXECUTE  I 

007C 

0808 

007E 

5E0E 

IF 

EQ  THEN 

0080 

008A' 

0082 

06  OC 

ANDB  BL4,  *1(2) 11110111 

!  EXECOTE  MASK 

0084 

F7F7 

0086 

5E08 

ELSE 

0088 

008E* 

008A 

060C 

AMDB  RL4 ,  *1(2)  11111110 

!  BEAD  MASK  ! 

008C 

PEFE 

FI 

008E 

84  BC 

OBB 

BL4,  BL3 

0090 

2EAC 

LDB 

SB  10,  BL4 

0092 

9E08 

BET 

0094 

END  OPDATE_MMO_IMAGE 
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0094  BAIT  PROCEDURE 

! *********************************** 

*  INTRA  KERNEL  SYNC/COM  PRIMATIVE  * 

*  INVOKED  BY  KERNEL  PROCESSES  * 


*  PARAMETERS  * 

*  R8(R9):  MSG  POINTER  (INPUT)  * 

*  R1 :  SENDING.VP  (RE TORN)  * 

*  GLOBAL  VARIABLES  * 

*  R14:  DBS  (PARAS  TO  GETB08K)  * 

*  LOCAL  VARIABLES  * 

*  R2:  CURRENT  VP  (RONNING)  * 

*  R3:  NEXT  READY_VP  * 

*  R4:  LOCK  ADDRESS  * 

*  R13:  LOGICAL  CPO  NUMBER  * 

***********************************1 
ENTRY 

I  MASK  INTERRUPTS  ! 

0094  7C01  DI  VI 

!  LOCK  VPT  ! 

0096  7604  LDA  R4,  VPT. LOCK 

0098  0000* 

009A  5P00  CALL  SPIN  LOCK  !  (R4:-»VPT.  LOCK)  ! 

009C  0282* 

!  NOTE:  RETURNS  BREN  VPT  IS  LOCKED  BY  THIS  VP  ! 
!  GET  CPU  NUMBER  ! 

009E  5P00  CALL  GBT_CPU_NO  ! RETURNS: 

00 AO  02C8' 

R1:CPU  * 

R2: *  VP'S! 


00A2 

A11D 

LD 

R13 ,  R 1 

00A4 

00A6 

61D2 

0002' 

LO 

R2,  VPT.RUNNING_LIST  (R 13) 

00A8 

OOAA 

6123 

001C' 

LD 

R3,  VPT. VP.NEXT_READY_VP(R2) 

00  AC 

4D2 1 

CP 

VPT.VP.MSG_LIST(R2) ,  #NIL 

OOAE  001E* 

00B0  FPFF 

00B2  5E0E  IF  EQ  !  CURRENT  VP'S  MSG  LIST  IS  EMPTY  1  THEN 
00B4  OOEA* 

!  REMOVE  CURRENT.VP  FROM  READY.LIST  1 
]  *  *  *  *  DEBUG  *  *  *  *  I 
00B6  0B03  CP  83,  *NIL 

00B8  FFFF 

OOBA  5E0E  IF  EQ  THEN 

OOBC  OOCA* 

OOBE  2100  LD  RO,  *R_L_E  !  READY  LIST  EMPTY  ! 

OOCO  0003 

OOC2  7601  LDA  R1,  $ 

00C4  00C2' 

00C6  5F00  CALL  MONITOR 

00C8  A900 
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FI 

!  *  *  *  END  DEBUG  ♦  *  *  ! 


OOCA  6FD3 
OOCC  0006' 
OOCE  4025 
OODO  001C' 
00D2  PPPF 


LD  VPT.BEADY_LIST  (B13)  ,  B3 

LD  VPT .  VP .  NEXT_BEADY_VP  (B2)  ,  *NIL 


00D4  4D25 
00D6  0014' 
00D8  0002 

OODA  612E 
00 DC  0010' 

OODE  93P8 

OOEO  93PD 
00E2  5F00 
00E4  0000* 


00E6  97FD 
00E8  97P8 


OOEA  5P00 
00 EC  Q0C2* 


1  PUT  IT  IK  BAITING  STAIE  I 
LD  VPT. VP. STATE (B2)#  AWAITING 


1  SET  DBB  ! 

LD  B14,  VPT.  VP.  DBB(B2) 

!  SCHEDULE  PIBST  ELGIBLE  BEADY  VP  ! 

PUSH  BB15,B8 

!  SAVE  LOGICAL  CPU  *  ! 

PUSH  3815,  B13 

CALL  GETNOBK  IB13:CPU  * 

B14:DBB! 

!  BESTOBE  CPU  *  ! 

POP  B13,  3B1 5 

pop  B8faai5 

FI 

!  GET  PIBST  HSG  ON  CUBBENT  VP'S  HSG  LIST  ! 

CALL  GET_PIBST_HSG  !  COPIES  HSG  IN  HSG  ABBAY! 

I  H13:  LOGICAL  CPU  «  ! 
IBETUBNS  B 1: SENDEE  VP  1 


!  UNLOCK  VPT  1 

OOEB 

4D08 

CLB  VPT. LOCK 

OOPO 

0000* 

1  UNHASK  VECTOBED  INTEBBUPTS  ! 

00P2 

7C05 

El  VI 

!  BETUBN:  B1 : SENDER_VP  ! 

00P4 

9E08 

BET 

00P6 

END  WAIT 
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00F6  SIGNAL  PROCEDURE 

| ************************************ 

*  INTRA_KERNEL  SYNC  /CON  PRIMATIVE  * 

*  INVOKED  BY  KERNEL  PROCESSES  * 

************************************ 

*  REGISTER  USE:  * 

*  PARAMETERS:  * 

*  R8(R9):  MSG  POINTER  (INPUT)  * 

*  R1:  SIGNALED  VP  ID  (INPUT)  * 

*  GLOBAL  VARIABLES  “  * 

*  R13:  CPU  #  (PABAM  TO  GETHORK)  * 

*  R14:  DBR  (PARAM  TO  GETHORK)  * 

*  LOCAL  VARIABLES:  * 

*  R1:  SIGNALED  VP  * 

*  R2:  CURRENT  VP  * 

*  R4 ;  VPT .  LOCK  ADDRESS  * 

************************************1 
ENTRY 

!  SAVE  VP  ID  ! 

00P6  93F1  PUSH  3R15,  R1 

1  MASK  INTERRUPTS  ! 

00F8  7C01  DI  VI 

!  LOCK  VPT  ! 

OOFA  7604  LDA  B4,  VPT. LOCK 

OOFC  0000* 

OOFE  5F00  CALL  SPIN  LOCK  !  (H4:  -»VPT.  LOCK)  i 

0100  0282* 

(NOTE:  RETURNS  HHEN  VPT  IS  LOCKED  BY  THIS  VP. 
!  GET  LOGICAL  CPU  *  ! 

0102  5F00  CALL  GET  CPU  NO  ! RETURNS: 

0104  02C8* 

R1:CPU  * 

R2:i  VP'S! 

0106  A11D  LD  R13,  R1 

!  RESTORE  VP  ID  ! 

0108  97F1  POP  R1,  dR 15 

!  PLACE  MSG  IN  SIGNALED.VP* S  MSGJLIST  ! 

0 10A  5F00  CALL  ENTER.MSG  LIST  !  (B8:HSG  POINTER 
010C  005C*  R1:SIGNALED_VP 

HI 3; LOGICAL  CPU  *)  ! 

010E  4D11  CP  VPT.  VP. STATE  (R1)  ,  AWAITING 

0110  0014* 

0112  0002 

0114  5E0E  IF  EQ  !  SIGNALED  VP  IS  HAITING  !  THEN 
0116  0148* 

1  HAKE  IT  UP  AND  HAKE  IT  READY  ! 


0118 

A112 

LD 

R2, 

R1 

011A 

one 

76D3 

0006* 

LDA 

83, 

VPT. READY_LIST (B13) 

01 1 E 
0120 

7.  ?4 

Ou 

JA 

84, 

VPT. VP.NEXT_READY_VP 

'I 


0122  7605 
0124  0012* 
0126  7606 
0128  0014* 
012A  2107 
012C  0001 

012E  93PD 
0130  5P0Q 
0132  0000* 


0134  97PD 

0136  6102 
0138  0002' 
013A  4D25 
013C  0014* 
013E  0001 

0140  612E 
0142  0010* 


LDA 

R5, 

VPT. VP.PRI 

LDA 

R6  , 

VPT.  VP. STATE 

LD 

R7  $ 

iREADY 

!  SAVE  LOGICAL  CPO  #  i 

POSH  BR15,  B13 

CALL  LIST.INSEBT  !R2:  OBJ  ID 


R3:  LIST.PIR  AOOR 
R4:  NEYT~OBJ,.PTR 
R5:  PRIQRITY”ptR 
R6:  STATE  PlI 
R7:  STATE-  ! 


!  RESTORE  LOGICAL  CPU  *  i 
POP  R13,  9R 1 5 

!  PUT  CURREHT_VP  IN  READY_SIATE  I 
LD  R2,  VPT. RONNING_LIST (R13) 


LO 


VPT.  VP. STATE  (R2)  ,  #READY 


!  SET  DBS  ! 

LD  R14,  VPT .  VP.  DBR  (R2) 


0144  5F00 
0146  0000 « 


!  SCHEDULE  FIRST  ELGIBLE  READY  VP  ! 
CALL  GETRORK  IR 13: LOGICAL  CPU  # 


FI 


R 14 : DBR  ! 


!  UNLOCK  VPT  J 
0148  4D08  CLR  VPT. LOCK 
0 14A  0000* 

!  UNHASK  VECTORED  INTERRUPTS  ! 
014C  7C05  El  VI 

014E  9E08  RET 

0150  END  SIGNAL 
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0150 


0150  6112 
0152  0210* 


SET.PRiBMPT  PHOCEDOBE 

t  **************************** 

*  SETS  PREEMPT  INTERRUPT  ON* 

*  TARGET_VP.  CALLED  BY  TC„  * 

*  ADVANCE.  * 

******** ****** ************** 


*  REGISTER  USE:  * 

*  PARAMETERS:  ♦ 

*  RETARGET  VP_ID  (INPUT)  * 

*  LOCAL  VARIABLES  * 

*  Rlc  VP_INDEX  * 

***  **|*  **********************  J 

entry| 

!  NOlrE:  DESIGNED  AS  SAFE  SEQUENCE  SO  VPT  MEED 
NO(r  BE  LOCKED.  ! 

!  COjdVERT  VP— ID  TO  VP_INDEX  i 
LD  I  R2#  EXT_VP_LIST (R1) 


0154  4D25 
0156  0018' 
0158  FFFF 


015A  9E08 
015C 


I  TUIRN  ON  TGT_VP  PREEMPT  FLAG  ! 

LD  [  VPT7VP.  PREEMPT  (R2)  .  *ON 


!  **l  IF  TARGET  VP  NOT  LOCAL 

(  NOT  BOUND  TO  THIS  CPU  ) 

[IE,  IF  «CPO_SEG»CPU_ID<>VPI.  VP.  PH YS_CPU  (B 1 )  ] 
THEN  SEND  HARDHARE  PREEMPT  INTERRUPT  TO 
VP|r.VP.CPU(Rl)  .  **  1 

RET 

END  SET  PREEMPT 
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PBOCEDUBE 


015C  IDLE 

!  ***«! 

*  LOADS  IDLE  DBS  ON  * 

*  CURRENT  VP.  CALLED  BY  * 

*  TC_GETHORK.  * 

************************* 

*  BEGISTSB  USB  * 

*  GLOBAL  VABIABLE  * 

*  B13:  LOG  CPU  *  * 

*  B14:  DBB  * 

*  LOCAL  VARIABLES:  * 

*  B2:  CURRENT  VP  * 

*  B3:  TEMP  VAB  * 

*  B4 :  VPT. LOCK  ADDB  * 

*  B5:  TEMP  * 

*************************1 
ENTBY 

!  GET  LOGICAL  CPO  *  ! 

0 15C  5POO  CALL  GET_CPO_NO  ! RETURNS: 

!  LOAD  IDLE  DBB  ON  COBBEMT  VP  ! 

0174  6103  LD  R3,  PBDS.IDLE  VP 

0176  OA 10 ' 

0178  6135  LD  85,  VPT.  VP  .DBB  (R3) 

017A  0010* 

017C  6F25  LD  VPT. VP. DBB  (B2) ,  B5 

017E  0010* 

I  TORN  ON  COB BENT  VP'S  IDLE  FLAG  ! 
0180  4D25  LD  VPT. VP. IDLE  FLAG (B2) ,  #ON 

0182  0016' 

0184  FFFF 

!  SET  VP  TO  BEADY  STATS  ! 

0186  4D25  LD  VPT. VP. STATE  (B2) ,  *BEADY 

0188  0014* 

018A  0001 

!  SCHEDULE  FIBST  ELIGIBLE  BEADY  VP  I 
018C  5F00  CALL  GETWOBK  !B13:LOGICAL  CPO  * 
018E  0000' 

B 14 :DBB  ! 

I  UNLOCK  VPT  ! 

0190  4D08  CLB  VPT. LOCK 
0192  0000* 

1  UNtlASK  VECTORED  INTERRUPTS  ! 

0194  7C05  El  VI 

0196  9B08  BET 

0198  END  IDLE 
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0198  SHAP_VDBR  PROCEDURE 

f  ************************* 

*  LOADS  HER  DBR  ON  * 

*  CURRENT  VP.  CALLED  BY  * 

*  TC_SET WORK.  * 

************************* 


*  RBGISTER  USE  * 

*  PARAMETERS  * 

*  R1:  HER  DBR  (INPUT)  * 

*  GLOBAL  VARIABLES  * 

*  R 13:  LOGICAL  CPU  *  * 

*  R14:  DBR  * 

*  LOCAL  VARIABLES  * 

*  R2:  CURRENT  VP  * 

*  R4 :  VPT. LOCK  AD DR  * 


*************************{ 

ENTRY 

!  SAVE  NEH  DBR  i 
0198  93F1  POSH  SR15,  R1 

!  MASK  INTERRUPTS  ! 

019A  7C01  DI  VI 

!  LOCK  VPT  ! 

0 19C  7604  LDA  R4,  VPT. LOCK 

019E  0000* 

01  AO  5 POO  CALL  SPIN  LOCK  i  (R4: -VPT. LOCK)  ! 

01A2  0282* 

1  NOTE:  RETURNS  RHEN  VPT  IS  LOCKED  BY  THIS  VP.! 
!  GET  CPU  *  ! 

01A4  5P00  CALL  GET  CPU  NO  ! RETURNS: 

01A6  02C8* 

HI:  CPU  * 

R2: #  VP'S! 

01A8  A11D  LD  R13«  R1 

!  GET  CURRENT  VP  ! 

0 1 AA  61D2  LD  R2,  VPT. RUNNING.LIST (R 13) 

01 AC  0002' 

I  *  *  *  DEBUG  *  *  *  ! 

0 1 AE  4D2 1  CP  VPT.VP.MSG_LISI (R2) ,  «NIL 

0 1B0  001E» 

01B2  FPPP 

01B4  5E06  IF  NE  !  MSG  HAITING  !  THEN 

01B6  01C4* 

01B8  2100  LD  RO,  #S_N_A  !  SNAP  NOT  ALLOHED  ! 

01  BA  0005 

0 1BC  7601  LDA  R1,  *  JPCi 

01 BE  01BC* 

01C0  5F00  CALL  MONITOR 

0 1C2  A900 

FI 

!  *  *  END  DEBUG  *  *  ! 

!  5ET  DBR  i 

01C4  612E  LD  R14,  VPT. VP. DBR(R2) 

01C6  0010* 

!  RESTORE  NEW  DBR  ! 
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01C8  97F0  POP  BO,  SB  15 

01C&  5 POO  C&LL  SET  OBB  AD  DR  1  (BO:  OBB  *) 

OICC  OOOA* 

BEXUBMS 

(B1:  OBB  AOOB)  1 

I  LOAD  NEH  OBB  OM  CURRENT  VP  i 
OICE  6F21  LO  VPT.VP.DBR  (R2) ,  B1 

01  DO  0010* 

I  TORN  OFF  IDLE  FLAG  ! 

0102  4D25  LO  VPT. VP. IDLE  FLAG (R2) ,  #OFP 

01D4  0016* 

0106  0000 

!  SET  VP  TO  BEADI  STATE  ! 

0108  4025  LO  VPT. VP. STATE  (R2) ,  *READY 

0 IDA  0014* 

01  DC  0001 

!  SCHEDULE  FIBS!  ELGIBLE  READY  VP  ! 

01DE  5F00  CALL  GETHORK  !B13:L0GICAL  CPU  I 
0 1 EO  0000' 

R  14 :OBB  1 

!  UNLOCK  VPT  1 
01E2  4D08  CLB  VPT. LOCK 
01E4  0000* 

!  UNHASK  VECTORED  INTERBUPTS  ! 

01E6  7C05  El  VI 

0 1E8  9E08  RET 

01EA  END  SNAP  VDBR 
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01  BA  PHI S_PREEMPT_H ANDLER  PROCEDURE 

j  *** ********41** ******4141* ********* 

*  HARDWARE  PREEMPT  INTERRUPT  * 

*  HANDLES.  ALSO  TESTS  FOR  * 

*  VIRTUAL  PREEMPT  INTERRUPT  * 

*  PLAG  AND  INVOKES  INTERRUPT  * 

*  HANDLER  IF  FLAG  IS  SET.  * 

*  INVOKED  UPON  EVERY  EXIT  FROM  * 

*  KERNEL.  KERNEL  FCH  MASKS  * 

*  NVI  INTERRUPTS  TO  PREVENT  * 

*  SIMULTANEOUS  PREEMPT  INTERR.  * 

*  HANDLING.  * 

******************************** 

*  REGISTER  USE  * 

*  LOCAL  VARIABLES  * 

*  R1 :  PREEMPT  INT  FLAG  * 

*  R2:  CURRENTJTP  * 

*  GLOBAL  VARIABLES  * 

*  HI 3: LOGICAL  CPU  #  * 

*  R14: DBR  « 

******************************** I 


ENTRY 

!  *  *  PREEMPT  HANDLER  *  *  ! 


!  SAVE 

ALL  REGISTERS  ! 

0  1  EA 

030F 

SUB 

R15,  *32 

01  EC 

0020 

01  EE 

1CF9 

LDM 

3R15,  HI, 

*16 

0  1F0 

010P 

!  SAVE 

NORMAL  STACK  POINTER 

(NSP) 

01P2 

7D67 

LDCTL 

R6,  NSP 

01F4 

93F6 

PUSH 

3R15,  R6 

!  GET 

CPU  *  ! 

01F6 

5POO 

CALL 

GET_CPU_NO 

(RETURNS: 

0 1F8 

02C8' 

HI :  CPU 

* 

R2:#  VP* 

si 

0  1FA 

A11D 

LD 

R13,  R 1 

!  MASK 

INTERRUPTS 

! 

0 1FC 

7C01 

DI 

VI 

!  LOCK 

VPT  l 

0  1FE 

7604 

LDA 

R4 ,  VPT. LOCK 

0200 

0000* 

0202 

5F00 

CALL 

SPIN.LOCK 

0204 

0282* 

(RETURNS  WHEN  VPT 

IS  LOCKED! 

!  SET 

DBR  ! 

0  206 

6 1D2 

LD 

R2,  VPT.RUNNING_.LISI  (R1  3) 

0208 

0002* 

020A 

612E 

LD 

R 14,  VPT. 

VP. DBR  (R2) 

020C 

0010* 
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!  PUT  CURRENT  PROCESS  IN  BEADY  STATE  ! 


020E 

0210 

0212 

4D25 

0014* 

0001 

LD 

YPT. YP. STATE  (R2) , 

iREADY 

0214 

0216 

5F00 

0000' 

CALL 

GETBORK  IB  13: LOG 

CPU  * 

B14:DBB  t 

PREEMPT  BET: 

1  UNLOCK  YPT  i 


0218  4D08  CLB  YPT. LOCK 
02 1 A  0000* 

!  UNHASK  VECTORED  INTERRUPTS  ! 

02 1C  7C05  El  VI 

KERNEL  EXIT: 

!  ***  UNHASK  VIRTUAL  PREEMPTS  ***  ! 

!  **  NOTE:  SAFE  SEQUENCE  AND  DOES  NOT  REQUIRE 
YPT  TO  BE  LOCKED.  **  ! 

1  GET  COBB ENT. YP  ! 

02 IE  610D  LD  R13,  PBDS.LOG_CPO.ID 

0220  OAOC' 

0222  61D2  LD  H2,  YPT. BONNING  LIST  (R13) 

0224  0002* 

!  TEST  PREEMPT  INTBBROPT  FLAG  ! 

0226  4D21  CP  YPT.  VP. PREEMPT  (B2) ,  #0N 

0228  0018* 

022A  FFFF 

022C  SEOE  IF  EQ  !  PREEMPT  FLAG  IS  ON  !  THEN 
022E  0240' 

!  BESET  PREEMPT  FLAG  ! 

0230  4D25  LD  YPT. YP. PREEMPT  (B2) ,  #OFF 

0232  0018* 

0234  0000 

!  SIMULATE  YIRTOAL  PREEMPT  INTERROPT  ! 

0236  2101  LD  B1,  *0 

0238  0000 

023A  6112  LD  R2,  YPT. YIBT.INT.YEC (R 1) 

023C  OOOC' 

023E  1E28  JP  SR 2 

! NOTE:  THIS  JUMP  TO  TRAFFIC.CONTBOL 
IS  USED  ONLY  IN  THE  CASE  OF  A  PREEMPT  INTERRUPT, 
AND  SIMULATES  A  HARDNARE  INTERRUPT.  **  ! 

!  ***  END  VIRTUAL  PREEMPT  HANDLER  ***  ! 

FI 

1  NOTE:  SINCE  A  HDWE  INTERRUPT  DOES  NOT  EXIT 
THROUGH  THE  GATE,  THOSE  FUNCTIONS  PROVIDED 
BY  A  GATE  EXIT  TO  HANDLE  PREEMPTS  MUST  BE 
PROVIDED  HERE  ALSO.  I 
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1  RESTORE  NSP  ! 


0240 

97P6 

POP  R6 , 

AR15 

0242 

7D6F 

LOCTL  NSP,  R6 

!  RESTORE  ALL  REGSTERS 

0244 

0246 

1CP1 

010? 

LDH 

HI ,  AR  15,  #16 

0248 

010? 

ADD 

R15,  #32 

024A  0020 

!  EXECUTE  HARDWIRE  INTERRUPT  RETURN  ! 
024C  7B00  IRET 

024E  END  PHTS_PREESPT_HANDLER 
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0  24E 


PROCEDORE 


ROM NING.TP 

|  **********! 

*  CALLED  BY  TRAFFIC  CONTROL. 

*  RETORNS  TP  ID.  BESOLI  IS  TALID 

*  ONLY  NHILE'aPT  IS  LOCKED. 


*  REGISTER  OSE 

*  PARAMETERS 


*  Bis 

EXT  TP.ID  (RETUiNED)  * 

*  R3 : 

LOG  CPO  #  (RETOBNED)  * 

*  LOCAL  7ABIABLES  * 

♦  R2 

;  TP  INDEX  * 

******************************«**! 

ENTRY 

(  MASK 

INTEBBOPTS  ! 

024E 

7C01 

DI 

TI 

!  LOCK 

TPT  ! 

0250 

7604 

LDA 

R4 ,  TPT. LOCK 

0252 

0000* 

0  254 

5F00 

CALL 

SPIN.LOCK  !  (B4: -TPT. LOCK)  I 

0256 

0282* 

!  NOTE 

:  RETOBNS  HHEN  TPT  IS  LOCKED  BY  THIS 

!  GET 

LOGICAL  CPO  *  ! 

0258 

5F00 

CALL 

GET.CPO.NO  IBEIOBNS: 

025  A 

02C8* 

B1:  CPO  * 

R2:i  TP*  S ! 

025C 

A113 

LD 

S3,  HI 

025E 

6132 

LD 

R2,  TPT. BONNING  LIST(B3) 

0260 

0002* 

!  CONTEST  TP  INDEX  TO  TP  ID  1 

0262 

6121 

LD 

R 1 ,  TPT. TP.EXT.ID (R2) 

0264 

0020* 

I  *  *  *  DEBOG  *  *  *  ! 

0266 

0B01 

CP  B1,  INIL 

0268 

FFFF 

026A 

5E0E 

IF  EQ  !  KERNEL  PBOC  !  THEN 

026C 

027A* 

026E 

2100 

LD  BO,  #T_I_E  1  TP  INDEX  EBBOB 

0270 

0006 

0272 

7601 

LDA  B 1 ,  $ 

0274 

0272* 

0276 

5F00 

CALL  MONITOR 

0278 

A900 

FI 

!  *  *  END  DEBOG  *  *  1 

!  ONLOCK  TPT  ! 

027A 

4D08 

CLB 

TPT. LOCK 

027C 

0000* 

!  OHM ASK  TECTOBED  INTEBBOPTS  1 

027E 

7C05 

El 

TI 

0280 

9B08 

BET 

0282 


END  BOHNING.TP 
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0282 


SPIN  LOCK  PROCEDQHE 
! ************************* 

*  OSES  SPIN  LOCK  NECH.  ♦ 

*  LOCKS  ONLOCKED  DATA  * 

*  STHOCTOHB  (POINTED  TO  * 

*  BY  INPOT  PARAMETER)  .  * 

************************* 

♦REGISTER  OSE  ♦ 

*  PAR A8BTERS  • 

*  R4  :  LOCK  ADDR  (INPOT)  ♦ 
*************************! 

ENTRY 

!  NOTE:  SINCE  ONLY  ONE  PROCESSOR  CORRENTLY 
IN  SYSTEfi,  LOCK  NOT  NECESSARY.  ♦♦  1 
j  *  *  *  DEBOG  ♦  ♦  ♦  ! 

0282  0D4 1  CP  9R4,  *OFF 

0284  0000 

0286  5E06  IF  NE  !  NOT  ONLOCKED  !  THEN 

0288  0296* 

028A  2100  LD  HO,  *0  L  i  ONAOTHORIZED  LOCK  1 

028C  0000 

028E  7601  LDA  R1,  $ 

0290  028E* 

0292  5FOO  CALL  MONITOR 

0294  A900 

FI 

!  ♦  ♦  END  DEBOG  •  •  I 
TEST  LOCK: 

!  DO  BHILE  STROCTORE  LOCKED  1 
0296  0D46  TSET  3R4 

0298  ESFE  JR  MI,  TEST  LOCK 

T  ♦♦  NOTE  SEE  PLZ/ASH  MANOAL 
FOR  RESTRICTIONS  ON 
OSE  OF  TSET.  *♦  I 

029A  9B08  RET 

029C  END  SPIN_ LOCK 
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029C 


PROCEDURE 


ITC  SET  SES  PTR 

I  *********************** 

*  SETS  BASE  ADDRESS  OF  SEGMENT  * 

*  INDICATED.  * 

********************************* 

*  REGISTER  USB:  * 

*  RO :  SEG  BASE  ADDRESS  (RET)  * 

*  R1 : SEG  NR  (INPUT)  * 

*  R2: RUNNING  VP  (LOCAL)  * 

*  R3: DBR  VALUE  (LOCAL)  * 

*  R4; VPT. LOCK  * 

*  R1 3: LOGICAL  CPU  #  * 

*** ******************************1 


ENTRY 

I  SA VI  SEG BEIT  *  ! 


0  29C 

93P1 

PUSH 

4R15,  HI 

!  BASK  INTERRUPTS  ! 

029E 

7C01 

DI 

VI 

!  LOCI  VPT  1 

02A0 

7604 

T.D  A 

R4r VPT. LOCK 

02A2 

0000* 

0  2A4 

5F00 

CALL 

SPIN_LOCK  ! 

84:-*  VPT.  LOCK 

02A6 

0282* 

!  GET 

CPU  *  ! 

02A8 

5F00 

CALL 

GET_CPO.NO 

(RETURNS: 

02AA 

02C8* 

R 1 :  CPU  * 

R2 : #  VP'S! 

02AC 

A11D 

LD 

R13f  81 

!  RESTORE  SEGMENT  * 

! 

02AE 

97F1 

POP 

R1 ,  9815 

02B0 

61D2 

LD 

82, VPT. RUNNING  LIST (813) 

02B2 

0002* 

02B4 

6123 

LD 

R3, VPT.VP. DBR (82) 

02B6 

0010* 

I  UNLOCK  VPT  ! 

02B8 

4D08 

CLR 

VPT. LOCK 

02BA 

0000* 

!  UNMASK  VECTORED  INTERRUPTS  i 

02BC 

7C05 

El 

VI 

02BE 

1900 

MULT 

RRO ,  #4 

0  2C0 

0004 

02C2 

7130 

LD 

80,83  (81) 

02C4 

0100 

02C6 

9E08 

RET 

02C8 

END  ITC.GET.SEG.PTR 

r 


02C8  GET_CPO_NO  PROCEDURE 

•  ************************* 

*  FIND  CURRENT  CPO  NO  * 

*  CALLED  BY  DIST  SHGR  * 

*  AND  EH  * 

************************* 

*  RETORMS  * 

*  R1:  CPO  NO  * 

*  R2:  #  OF  VP'S  * 

*************************  I 


ENTRY 


0  2C8 

6101 

LD 

R1,  PRDS.LOG_CPU_ID 

02CA 

OAOC* 

02CC 

6102 

LD 

S2,  PRDS . VP_NR 

02CE 

OAOE* 

02D0 

9308 

RET 

02D2 

END  GET_CPU_NO 

02D2 

K 

LOCK 

PROCEDORE 

( ************************* 

*  STUB  FOR  BAIT  LOCK  * 

************************* 

*  R4:-»LOCK  (INPOT)  * 

***************4>*********  1 

ENTRY 

0202  5F00  CALL  SPIN  LOCK 

02D4  0282' 

02D6  9E08  RET 

02D8  END  K— LOCK 

02D8  K.ONLOCK  PROCEDORE 

I  ************************* 

*  STUB  FOR  BAIT  UNLOCK  * 

************************* 

*  R4J-LOCK  (INPUT)  * 

*************************1 

ENTRY 

02D8  0D48  CLR  8R4 

02DA  9E08  RET 

02 DC  END  K_ UNLOCK 

END  INNER  TRAFFIC  CONTROL 
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Appendix  H 

SEGNENT  HANAGER  LISTINGS 

Z8000ASN  2.02 

LOC  OBJ  CODE  ST  NT  SOOBCE  STATEHENT 

$ LI ST ON  STTT 

SES  HGH  NODOLE 


CONSTANT 

NOLL  SEG  :»  -1 

NOLL  ACCESS  :  =  4 

aAX_SBG_NO  I-  64 

H AX  NO  KST  ENTRIES  :=  54 

NAX  SEG  SIZE  :*  128 

KST  SEG  NO  :*  2 

NR_OP_KSEGS  J»  10 

TROE  ”  1=  1 

FALSE  :»  0 

READ  :«  1 

WRITE  :»  0 

I  «***  SOCCESS  CODES  ****  I 
SOCCEEDED  :»  2 


NENTOB  SEG  NOT_KNORN  :«  22 
ACCESS  CLASS  NOT  EQ  :»  33 
NOT  CONPATIBLE  :*  24 

SEGNENT  TOO  LARGE  :*  25 
NO_SEG_I?AIL  :■  27 

SEGNENT  NOT  KNOWN  :»  28 
SEGNBNTllN_CORE  :»  29 

KERNEL  SEGNENT  :*  30 

IN?ALID_SEGHENT_NO  :*  31 
NO  ACCESS  PERNITTED  i«  32 
LEAF  SEG.EXISTS  :*  10 

NO  LEAF  EXISTS  :*  11 

ALIAS_DOES_NOT_EXIST  :=  23 
NO  CHILD  TO  DELETE  :»  20 
S  AST  POLL  ”  ;*  12 

L_AST_FOLL  :■  13 

PROC_CLASS_NOT_GE_SEG  CLASS  :=  41 
LOCAL_NEHORT_POLL~  7*  16 
GLOBAL  NENORT  POLL  :»  17 
SEC_STOR_POLL  :«  21 
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0000 


1 


MONITOR 


XQ59A 


TYPE 

H_ARR AY 

KST_REC 


ARRAY  [  3  NOR 0  ] 


RECORD 


t  MM  HANDLE 
SIZE 

ACCESS  MODE 
IN  CORE 

clIss 

M  SES  NO 
ENTRY  NUMBER 

] 


H  ARRAY 

WORD 

BYTE 

BYTE 

LONG 

SHORT  INTEGER 
SHORT  INTEGER 


ADDRESS 


WORD 


SEGJkRRAY  ARRAY  [ MAX_SEG_SIZE  BYTE] 


INTERNAL 

{SECTION  SM_KST_DCL 

J  NOTE:  THIS  SECTION  IS  AN  "OVERLAY" 

OR  "FRAME"  USED  TO  DEFINE  THE 
FORMAT  OF  THE  KST.  NO  STORAGE 
IS  ASSIGNED  BOT  BATHER  THE  KST  IS 
STORED  IN  A  SEPARATELY  OBTAINED 
AREA  (A  SEGMENT  SET  ASIDE  FOR  IT)  1 

SA3S  0 

KST  ARRAY  MAX_NO_KST_ENTRIES  KST_REC 

EXTERNAL 

CLASS^EQ  PROCEDURE 
CLASS  GE  PROCEDURE 
MM_CRBATE_ENTRY  PROCEDURE 
MM~DELETE  ENTRY  PROCEDURE 
MM  ACTIVATE  PROCEDURE 
MM~DE ACTIVATE  PROCEDURE 
MM  SNAP  IN  PROCEDURE 
NH”SNAP”0UT  PROCEDURE 
PBOCSSSZCLASS  PROCEDURE 
ITC  GET  SEG  PTR  PROCEDURE 
SET  DBR  NUMBER  PROCEDURE 
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{SECTION  SH.PROC 
GLOBAL 

0000  CBEATE.SEG  PH OC ED USE 

I  ****************************** 

!  CHECKS  VALIDITY  0?  CREATE 
!  REQUEST  AND 

!  CALLS  HH.CREATE  IP  VALID. 

] ****************************** 

!  REGISTER  OSE: 

!  PARAMETERS 

!  R1:  MENTOR  SEG.NO  (INPOT) 

I  R2:  ENTRY  NO(INPOI) 

!  R3  :  SIZE  (INPOT) 

!  RR4:  CLASS  (INPOT) 

!  BO:  SOCCESS.CODE  (RETORNED) 
i  LOCAL  OSE 
1  R9 :  KST  REC  INDEX 
!  R6,R7  VARIOUS  OSES 

!  R13:  **KST 

•  ****************************** 


ENTRY 

0000 

0B03 

CP  R3 

,#HAX_SEG_SIZE 

0002 

0080 

0004 

5E02 

IF  GT 

THEN 

0006 

0010* 

0008 

2100 

LD 

RO , #SEGMENT_TOO_L ARGE 

OOOA 

0019 

000 C 

5E08 

ELSE 

OOOE 

00A2' 

0010 

030P 

SOB 

R15, #10  {STACK  AREA  FOR 

INPOT  REGS1 

0012 

OOOA 

0014 

1CF9 

LDH 

9R15,R1,#5 

0016 

0104 

0018 

2101 

LD 

R1,#KST_SEG_N0 

001 A 

0002 

00 1C 

5F00 

CALL 

ITC_GET_SBG_PTR  IBls  KST_SEG_NO! 

00  IE 

0000* 

!  RET:  RO: **KST ! 

0020 

A10D 

LD 

H 13, HO  IKST  BASE  ADDRESS 

(IE  -KST)! 

0022 

1CF1 

LDH 

R1,dR15,#5  {RESTORE  NEEDED  BEGS! 

0024 

0104 

0026 

A119 

LD 

R9,R1  ICOPY  OF  HENTOR.SEG.NO! 

0028 

0309 

SOB 

R9 , #NR  OF  KSEGS  {CONVERT 

HENTOR_SEG.NO 

002A 

OOOA 

KSZ.REC  INDEX! 

002C 

1908 

HOLT 

RR8 , ISIZEOF  KST.REC 

iOFFSET  TO  KST.RECt 
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002E 

0010 

0030 

8 19D 

ADO  R  13,39  ! ADD  OFFSET  TO  KST 

BASE  ADDBESS! 

0032 

2106 

LD  R 6 , #  N  0 LL  SEG 

0034 

FPPF 

0036 

4ADE 

CPB  RL6 , KST .H_SEG  H0(B13) 

0038 

000E 

003A 

5E0E 

IP  EQ 

THEN  ! BENT OB  SEG  NOT  KNOHN! 

003C 

0046' 

003E 

2100 

LD 

RO, #MENTOB_SEG_NOT_KNOH  N 

0040 

0016 

0042 

5E08 

ELSE 

0044 

009E* 

0046 

93PD 

POSH 

3R15,B13 

0048 

5P00 

C  \L 

P HOC ESS_C LASS  ! BB2: PBOC _CLASS! 

004A 

0000* 

004C 

97PD 

POP 

3 1 3, 3B1 5 

004E 

54D4 

LOL 

RR4, KST. CLASS  (B13) 

0050 

OOOA 

0052 

93FD 

PUSH 

aai5,Bi3 

0054 

5P00 

CALL 

CLASS.EQ  1 RB2:  PBOC.CLASS! 

0056 

0000* 

IBB 4:  HENTOB  SEG  CLASS! 

!B1 :  (SET) CONDITION  CODE! 

0058 

97FD 

POP 

R13,£B15 

005A 

A116 

LD 

B6,B  1 

005C 

1CF1 

LDH 

R  1 ,3H15 , #5  ! RESTORE  INPOT  BEGS! 

005E 

0104 

0060 

0B06 

CP 

R6, iPALSE 

0062 

0000 

0064 

5E0E 

IP  EQ  THEN 

0066 

0070* 

0068 

2100 

LD 

BO , #ACCESS_CLASS_NOT_EQ 

006  A 

0021 

006C 

5B08 

ELSE 

006E 

009E* 

0070 

93PD 

POSH  dB 15, B1 3  1SAVE  -.KST! 

0072 

9442 

LDL 

BB2,BB4  ! CLASS! 

0074 

54D4 

LDL 

RB4, KST. CLASS  (H13) 

0076 

OOOA 

0078 

5P00 

CALL  CLASS  6E  !BB2:CLASS! 

007A 

0000* 

I RR4: MENTOR  CLASS! 
! SET :  B1 :COND  CODE! 


007C 

97PD 

POP 

R13,dB15  IBESTOBE  PTB! 

007E 

0B0 1 

CP 

HI , #PALSE 

0080 

0000 

0082 

1CP1 

LDH 

B1,EB15,*5 

0084 

0104 

0086 

5E0E 

IP 

EQ  THEN 

0088 

0092' 

008A 

2100 

LD 

BO,»NOT_COHPATIBLE 
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008C  0018 
008B  5E08 
0090  009E* 
0092  76D1 
0094  0000 
0096  5F00 
0098  0000* 


0094  5F00 
009C  0428* 


ELSE 

LDi  ai,KST.aajiMDLE(ai3l 

CALL  Mfl_CREATE_ENTBI 

! R1 : PTH  TO  HH  HANDLE! 

! B2; ENTBI  SO! 

!B3:SIZEl” 

!RB4:CLASS! 

ISO: (RETURNED) SUCCESS  COOE1 
CALL  COUP  MEM  EHT  CHECK 


!  (BO  :SUCCESS  CODE)  1 
FI 
FI 
FI 

009E  010F  ADD  H15,#10 
00 AO  OOOA 

FI 

00A2  9E08  BET 

00A4  BID  CHEATS  SEG 
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00A4  DELETE_SEG  PROCEDURE 

1  ***************************** 

!  CHECKS  VALIDITY  OP  DELETE 
!  BEQUEST  AMD 

!  CALLS  HM_DELETE  IF  VALID. 

{ ***************************** 

!  REGISTER  USE: 

!  PARAMETERS 

!  R 1 : MENTOR  SEG  NO (INPUT) 

!  B 2: ENTRY  NO (INPUT) 

!  R0: SUCCESS  CODE  (BET) 

!  LOCAL  USE 

!  B6:  VARIOUS  LOCAL  USES 

•  ***************************** 


ENTRY 

00A4 

93P 1 

PUSH 

3R  15, R 1  1  SAVE  NEEDED  BESS! 

00A6 

93P2 

PUSH 

iR 15, R2 

00A8 

2101 

LD 

R1 , #KST_ SEG_NO 

00  AA 

0002 

00  AC 

5F00 

CALL 

ITC_GET_SEG_PTR  I  HI: KST_SEG_NO ! 

00  AE 

0000* 

00B0 

A10D 

LD 

HI  3, BO  1-»KST! 

00B2 

97P2 

POP 

R2 , 3B 15  1BEST0BE  INPUT  BESS! 

00B4 

97P1 

POP 

R1,9H15 

00B6 

0301 

SUB 

R 1 , #NB  OF  KsEGS  ICONVEBT 

MBNTOB„SEG_NO  TO 

00B8 

OOOA 

KST  BEC  INDEX! 

OOBA 

1900 

MULT 

RBO, #SIZEOF  KST_BEC  ! OFFSET 

TO  DESIRED  BEC! 

OOBC 

0010 

OOBE 

81  ID 

ADD 

R1 3  y B 1  !  ADD  OFFSET  TO  KST  BASE 

ADDBESS! 

OOCO 

2106 

LD 

B6 , #NULL_SEG 

00C2 

PFFP 

00C4 

4ADE 

CPB 

RL6,KST. M_SEG_NO (B13) 

00C6 

OOOE 

00C8 

5E0E 

IF 

EQ  THEN  ! MENTOB  SEGMENT 

NOT  KNOHN! 

OOCA 

00D4* 

OOCC 

2100 

LD 

RO, #HENTOB_SEG_NOT_KNOHN 

OOCE 

0016 

OODO 

5E08 

ELSE 

00D2 

010E* 

00D4 

93F1 

POSH 

3R15, R 1  ISAVE  NEEDED  BEGS! 

00D6 

93F2 

PUSH 

3B15, B2 

00D8 

93FD 

POSH 

iB15,R  13 

OODA 

5F00 

CALL 

P ROC ESS_C LASS 

OODC 

0000* 

!  (BETOBNS  RB2 :PBOC_CLASS)  ! 

OODE 

97FD 

POP 

R13,3R15 

OOEO 

54  D4 

LDL 

RB4, KST. CLASS  (R13)  ! MENTOB 
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SES  CLASS  1 


00E2  OOOA 

00E4  93FD  POSH  9R15,R13 

00E6  5P00  CALL  CLASS  EQ  !RR2:PBOCESS  CLASSI 

00E8  OOOO* 

! BB4 : HENTOfi  SES  CLASSI 
! B 1 :  (BET)  CONDITION .CODE! 

OOEA  A116  LD  R6,R1 

00 EC  97PD  POP  R13,9B15 

OOEE  97P2  POP  R2*  3B 1 5  IBESTOBE  HEEDED  BESS! 

OOPO  97P1  POP  R1,3B15 

00F2  0B06  CP  R6, iPALSE 

00P4  0000 

00P6  5E0E  IP  EQ  THEN 

00F8  0102* 

OOPA  2100  LD  B0,*ACCESS  CLASS  NOT  EQ 

OOPC  0021 

OOPE  5E08  ELSE 

0100  Q10E' 

0102  76D1  LD A  B1,KST.NH  HANDLE (B13) 

0104  0000 

0106  5F00  CALL  HH.DELETB  ENTBY 

0108  0000* 

!B1:-NH  HANDLE! 

! B2:BNTBY_N0! 

!R0:  (BET)  SUCCESS  CODE! 

0 1 OA  5P00  CALL  CONPINEHENT  CHECK 

010C  0428* 

!  (BO: SUCCESS  CODE)! 

PI 

FI 

0 10E  9E08  RET 

0110  END  DELST E  SES 
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0110  MAKEJCNOtfN  PROCEDURE 

{ *******************************{ 

!  CHECKS  VALIDITY  OF  HAKE  KNOWN  ! 
!  REQUEST  AND  CALLS  REACTIVATE  i 
!  IF  VALID.  ASSIGNS  SEG  ! 

!  NUMBER  AND  UPDATES  KST.  ! 

i *******************************} 

!  REGISTER  USE:  ! 

!  PARAMETERS:  i 

!  HI :MENTOR  SEG  NO  (INPUT)  ! 

!  R2:£NTRY  NO  (INPUT)  I 

!  R3 : ACCESS  DESIRED (INPUT)  ! 

!  RO: SUCCESS  CODE  (RET)  1 

!  HI :SEGMENT~NO (BET)  1 

!  H2:  ACCESS  ALLOWED  (RET)  ! 

!  LOCAL  USE  ~  1 

1  IDENTIFIED  AT  POINT  OF  USAGE  ! 

j  ft******************************  I 

ENTRY 


0110 

93F 1 

PUSH 

SR  15, HI  !SAVE  INPUT  REGS! 

0112 

91F2 

PUSHL 

aa is , RR2 

0  114 

2101 

LD 

R1,#KST_SEG_NO 

0116 

0002 

0118 

5F00 

CALL 

ITCJ5ET_SEGJ?TE  I  (R1:KST_SEG  NO 

RET : BO: ->KST)  ! 

0  1 1 A 

0000* 

one 

A10D 

LD 

R1  3  ,  RO  i-KSTt 

0  1 1E 

95F2 

POPL 

HR2  ,SE15 

0120 

97F1 

POP 

Ri,aai5 

0122 

A115 

LD 

85 , HI  {COPY  OF  MENTOR  SEG  NO! 

0124 

0305 

SOB 

R5  «  #NH_OF_KSEGS  {CONVERT  TO 

INDEX { 

0126 

000k 

0126 

1904 

MOLT 

RR4(#SIZEOF  KST_REC  {KST  OFFSET 

TO  SEG  REC{ 

012A 

0010 

012C 

815D 

ADD 

HI  3rH5  I  ADD  OFFSET  TO  -.KSTI 

0  12E 

2104 

LD 

R4  0 #NULL_SEG 

0130 

FFFF 

0132 

4ADC 

CPB 

RL4,KST.  M_SEG_NO(R13) 

0134 

000E 

0136 

5E0E 

IF  EQ 

THEN 

0138 

014A' 

013A 

2100 

LD 

RO, #MENTOR_SEG_NOT_KNONN 

013C 

0016 

013E 

2101 

LD 

R1, •NULL.SEG 

0140 

FFFF 

0142 

2102 

LD 

R2,fN0LL_ACCESS 

0144 

0004 

0146 

5E08 

ELSE 

0148 

02C8* 

0 14A 

2107 

LD 

R7, #0  ! KST  INDEX) 

014C 

0000 
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LO 


R8, #NULL_SEG  i AVAIL  SEG  INDEX! 


0  14E 

2108 

LD  R8,#NULL_SEG  1  AVAIL  SEG  INDEX! 

0150 

FFFP 

0152 

A109 

LD  H9,R0  J-iKST! 

0154 

210A 

LD  R 10, #N ULL_SEG  !SEG  KNOWN  INDICATOR! 

0156 

PPPP 

SEE  IP  KNOBN: 

DO 

0158 

4A99 

CPB  RL1,KST.H_SEG_N0(B9) 

015A 

OOOE 

0  15C 

5E0E 

IF  EQ  THEN 

015E 

017C* 

0160 

4A9A 

CPB  RL2*  KST. ENTBX_NOMBEB (B9) 

0162 

OOOF 

0164 

5E0E 

IP  EQ  THEN  ICASE:  SEG  KNOBN! 

0166 

017C* 

0168 

2100 

LD  RO , iSOCCEED  ED 

0  16A 

0002 

0  16C 

0107 

ADD  R7 1 #NB_QF_KSEGS 

0  16E 

OOOA 

0170 

A171 

LD  B1,B7  ! S  EG  # ! 

0172 

609A 

LDB  RL2«KST.ACCESS_H0DE (B9) 

0174 

0008 

0176 

A11A 

LD  R1G,B1  ! SET  SEG  KNOBN 

INDICATOR! 

0178 

5E08 

EXIT  FROH  SEE_IF— KNOBN 

017A 

01A6  * 

PI 

PI 

0  17C 

4A9C 

CPB  RL4,KSI.H_SEG_N0(B9) 

! SEE  IF  SEG  *  AVAIL1 

0  17E 

OOOE 

0180 

5E0E 

IP  EQ  THEN 

0182 

0192' 

0184 

0B08 

CP  B8,*NULL_SEG 

0186 

PFPP 

0188 

5E0E 

IF  EQ  THEN 

018A 

0192' 

0 18C 

A178 

LD  R8,R7  ! SAVE  PIBSI 

AVAIL  SEG  INDEX! 

0 18E 

0108 

ADD  R8  f #NB  OP  KSEGS 

tCONVEBT  TO  SEG  *! 

0190 

OOOA 

PI 

PI 

0192 

A970 

INC  R7 

0194 

0109 

ADD  R9, tSIZEOF  KST.BEC 

1INCREHENT  ONE  BEC! 

0196 

0010 

0198 

0B07 

CP  R7, #MAX_NO_KST_ENTRIES 

0  19A 

0036 

019C 

5E02 

IP  GT  THEN 

0 19E 

01A4* 
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ouo 

5E08 

EXIT  FROM  SEE  IF.KNOBH 

0112 

0116' 

PI 

0114 

E8D9 

OD 

! SEE  IF  KNOWN! 

0116 

0B01 

CP  “  B10,*NOLL_SEG 

0118 

FFFF 

0111 

5E0E 

IP  EQ  THEN  1 SES  KNOWN 

INDIC1TOR  NOT  SET! 

01 1C 

02C8 ' 

0118 

0B08 

CP  R8, *NULL  SEG 

0  1B0 

PPPP 

01B2 

5E06 

IP  HE  THEN  ! C1SE :SEG  UNKNOWN 

1ND  SEG*  1Y1IL! 

01B4 

02BC* 

0  1B6 

91P0 

POSHL 

BB 15, BBO  I^KST  1ND 

HENTOB.SEG.NO 1 

01B8 

91P2 

POSHL 

BB15,BH2  1ENTBY.NO 

&1CCESS  DESIRED  1 

01B1 

93P8 

POSH 

BB15,H8  ! 1V1IL  SEG 

INDEX  IN  KST1 

0 1 BC 

93PD 

POSH 

BB 15, R 13  1HENT0B  SEG  BEC  PTB1 

0  1  BE 

5P00 

C1LL 

GET  DBB  NOHBEB 

1 (BET: 

bliTdbb.no)  1 

01C0 

0000* 

01C2 

1111 

LD 

B1G,B1  ! DBB.N01 

0 1C4 

97PD 

POP 

B13,SB15 

01C6 

97F8 

POP 

B8,BB15 

01C8 

95P2 

POPL 

BB2,BB15 

01C1 

95FG 

POPL 

BB0,BB15 

'.HOST  RE1RR1NG E  BEGS  POB  PISSING  1ND 

BETOBN  CONSISTENCY  OF  LOC1IION! 

01CC 

1135 

000D 

047C 

5E0E 

LD 

B5,B3  UCCESS  DESIBED! 

01CE 

1123 

LD 

B3,R2  JENTBY  NO! 

0  IDO 

76  D2 

LD1 

B2,KST. HH.H1NDLE (B 13)  1HPTB! 

01D2 

0000 

01D4 

1116 

LD 

R6,B1  1HENT0B_SEG.N0 ! 

01D6 

1181 

LD 

B1,B8  1SEGHENT.N0  (S1VE)  1 

0  1D8 

1184 

LD 

84 ,S8  1SEGHENT.N0 

(PISSING  1BG)  1 

01D1 

1109 

LD 

R9,B0  i-KSTl 

01DC 

030F 

SOB 

BIS, *20 

0  1 DE 

0014 

0  1E0 

1CP9 

LDH 

3R  15, fil ,* 10  1  SI YE  BEGS  1-10! 

01E2 

0109 

0  1E4 

1111 

LD 

R1,R10  l DBB.NO  PISSED 

IN  fill 

0  1E6 

118B 

LD 

R1 1,  B8 

0 1E8 

030B 

SOB 

HI  1 ,  *NB_OF_KSEGS 

0  1E1 

0001 

01  EC 

1901 

HOLT 

RB 10,  *SIZEOP  KST.BEC 

0  1EE 

0010 
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01P0 

A1BC 

LD 

B12,  B11 

01F2 

819C 

ADD 

B1 2,  B9 

01P4 

5P00 

CALL 

MB  ACTIVATE 

01P6 

0000* 

f N0,B2:HPTB,83:BNTBI  MO, 
B4;SEGHENT  NO,B12:BET  HPTB)  ! 

! (BET: BO: SUCCESS  CODE, BB  2: CLASS, 
B4 :SIZE) ! 


0 1P8 

5P00 

CALL  COMPINBMEMT  CHECK 

1(B0:SUCCESS  CODE)! 

0 1PA 

0428* 

01PC 

94  2 A 

LDL 

BB 10, BB2  l CLASS! 

01  PE 

A14C 

LD 

B12,B4  ! SIZE! 

0200 

1CP1 

LDH 

B1,9B15,#9  IBESTOBE 

BEGS  1- 

0202 

0108 

0204 

A187 

LD 

B7,B8  IS EG  •! 

0206 

0307 

SOB 

H7,#NH_OPJCSEGS 

0208 

000A 

020A 

1906 

HOLT 

BB 6,# SIZE OP  KSI  BEC 

IOFPSET  TO  BBC! 

020C 

0010 

020E 

A17D 

LD 

B13,B7 

0210 

819D 

ADD 

HI  3, B9  ! ADD  ->KSX  TO 

OPPSET! 

0212 

5DDA 

LDL 

KST. CLASS  (B13)  ,BB10 

! CLASS! 

0214 

000A 

0216 

6PDC 

LD 

KST. SIZE (B1 3) ,B12  ISIZE! 

0218 

0006 

021A 

0A08 

CPB 

BLO , iSOCC  EEDED 

0  2 1C 

0202 

02  IE 

5E0E 

IP  EQ 

THEN 

0220 

02AC' 

0222 

93FD 

POSH 

9B15,B13 

0  224 

5P00 

CALL 

PBOCESS.CLASS 

0226 

0000* 

!  (BET: BB2:PB0C  CLASS)  ! 

0228 

97PD 

POP 

B13,9B1 5 

022A 

54  D4 

LDL 

BB4, KST. CLASS (B13) 

022C 

000k 

022E 

93PD 

POSH 

9B15, B1 3 

0230 

91P2 

POSHL  9B15,BB2 

0232 

91P4 

POSHL  9B1 5, BB4 

0234 

5P00 

CALL 

CLASS_GE 

0236 

0000* 

!  (RR2 :  PBOC 

.CLASS, SR 4: S EG  CLASS 

,  BET: 

B1: 

CONDITION  CODE)  ! 

0238 

95P4 

POPL 

BB4 ,9B1  5 

023A 

95P2 

POPL 

BB2, 9B1 5 

023C 

97  PD 

POP 

B13,9B15 

0  23E 

OB0 1 

CP 

B 1, #FALSE 

0240 

0000 

0  242 

5E0E 

IP  EQ  THEN  !NO  ACCESS 

POSSIBLE — DBACT.  ! 

0244 

0266* 
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LDN 


HI, iB 15, #10 


0  246 

1CF1 

LDM 

R1,iB15,#10 

0246 

0109 

0  24  A 

A1A1 

LD 

HI, BIO  ! DB1  HO! 

024C 

76D2 

LDA 

B2, KST. HE  HANDLE (B13) 

1HPTB1 

024S 

0000 

0250 

5F00 

CALL 

HE  DEACTIVATE 

!BET:BO:S  CODE! 

0252 

0000* 

0254 

5F00 

CALL 

CONFI NEB ENT  CHECK 

!  BO:  S_CODE! 

0  256 

0428' 

0258 

21F1 

LD 

B1,»B15  ! SEG  *! 

025A 

2102 

LD 

B2,#H0LL_ ACCESS 

025C 

0004 

025E 

2100 

LD 

BO, 

iPBOC  CLASS  HOI  SB  jBG  CLASS 

0260 

0029 

026 2 

5E08 

ELSE 

0264 

02A8' 

0266 

93FD 

POSH 

BB15,B13 

0268 

5F00 

CALL 

CLASS.BQ  !  (BB2 : PBOC.CLASS 

026A 

0000* 

BB4 :SEG  CLASS, 

RET: B1 ZCONDITION  CODE)! 

026C 

97  FD 

POP 

B13,»B15 

0  26E 

A110 

LD 

BO, HI  ! CONDITION  CODE ! 

0270 

1CF1 

LDN 

B1,dB15, #9 

0272 

0108 

0274 

OBOO 

CP 

BO,  #TBOE 

0276 

0001 

0278 

5E0E 

IF  BQ  THEE 

027A 

0290* 

027C 

0B05 

CP 

B5, tHBITE 

027E 

0000 

0280 

5E0E 

IF 

EQ  THEN 

0282 

028A* 

0284 

CAOO 

LDB  BL2 , #HRITS 

0286 

5E08 

ELSE 

0288 

Q28C* 

028A 

CA01 

LDB  BL2 , #BEAO 

FI 

028C 

5E08 

ELSE 

028E 

0292* 

0290 

CA01 

LDB 

BL2,#BEAD 

FI 

0292 

4CD5 

LDB 

KST.IN.COBE (B13)  , #FALSE 

0294 

0009 

0296 

0000 

0298 

6E0E 

LDB 

KST.N_SEG.NO (B13)  ,BL6 

029A 

OOOE 

029C 

6E0B 

LDB 

KST.ENTBT.NDNBEB (B13)  ,BL3 

029E 

OOOF 

375 
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0210 

6EDA 

LDB 

0212 

0008 

0214 

2100 

LD 

0216 

0002 

PI 

0218 

5E08 

ELSE 

0211 

02B4' 

02  AC 

2101 

LD 

02AE 

PPPP 

02B0 

2102 

LD 

02B2 

0004 

KST. ACCESS_MODE  (S 13)  ,HL2 

HO, tSOCCEEDED 

JSOCCESS.CODE! 

HI, #NULL_SEG 
H2, *NULL_ ACCESS 


PI 


02B4 

02B6 

010P 

0014 

1DD 

BIS,  *20 

02B8 

02B1 

5E08 

02C8* 

ELSE 

02BC 

02BE 

2100 

00  IB 

LD 

BO,#NO_SEG_AVAIL 

0  2C0 
02C2 

2101 

PPPP 

LD 

B1,#N0LL_SEG 

02C4 

02C6 

2102 

0004 

LD 

PI 

PI 

PI 

B 2, *M DLL. ACCESS 

02C8 

9E08 

BET 

02CA  END  HAKE.KHOBH 


I 
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0  2CA 


TERMINATE 


PROCEDURE 


]  ****************************** 

!  CHECKS  VALIDITY  OP  TERMINATE 
!  REQUEST  AMD  CALLS 
1  NH_ DEACTIVATE  IF  VALID 

t ****************************** 

!  REGISTER  USE 
I  PARAHETERS 
!  HI :  SEGl!ENT_NO  (INPUT) 

!  RO :SUCCESSlcODE(RET) 

!  LOCAL  USE 
!  B3:KST  EEC  INDEX 
!  R6: CONST ANT  STORAGE 

!  R13:«KST 

I  ****************************** 


ENTRY 

02CA 

A113 

LD 

R3,R1  1  COPY  OF  SEG  »! 

02CC 

0303 

SUB 

R3,#NB  OF  KSEGS 

{CONVERT  SEG#  TO  KST  INDEX1 

0  2CE 

000A 

02D0 

1902 

HULT 

RR2, tSIZEOF  KST.REC 

02D2 

0010 

02D4 

93F1 

PUSH 

3R15,R1 

02D6 

93F3 

PUSH 

3R 15, R3 

02D8 

2101 

LD 

R1,#KST_SEGJ!0 

0  2DA 

0002 

02DC 

5F00 

CALL 

ITC  GET  SEG.PTR 
! (rT: KST_ SEG_NO)  ! 

02DE 

0000* 

1  (RETURNS: R0:KST_SEG_PTR|  1 

02E0 

A10D. 

LD 

R13,R0 

02E2 

97F3 

POP 

R3,iR15 

02E4 

97F1 

POP 

R1 ,dR 15 

02E6 

813D 

ADD 

R1 3 ,R3  ! ADD  OFFSET  TO  -KST 

02E8 

2106 

LD 

R6  t #NULL_SEG 

02EA 

FFFF 

02EC 

4ADE 

CPB 

RL6,KST. H_SEG_NO (R13) 

0  2BE 

000E 

02P0 

5B0E 

IF 

EQ  THEN 

02F2 

02PC* 

02P4 

2100 

LD  RO , #SEGHENT_NOI_KNOBN 

02F6 

001C 

02F8 

5E08 

ELSE 

02FA 

0346* 

02FC 

2106 

LD  R6,*TRUE 

02FE 

0001 

0300 

4ADE 

CPB  RL6,KST.IN_CORE (B13| 

0302 

0009 

0304 

5E0E 

IF 

EQ  THEN 

0306 

0310* 

0308 

2100 

LD  RO,*SEGHENT.IN_CORE 

377 


0301 

00  ID 

030C 

5E08 

ELSE 

0302 

0346* 

0310 

0801 

CP 

81, #NB_OF_KSEGS 

0312 

0001 

0314 

5E09 

IF  LT  THEN 

0316 

0320* 

0318 

2100 

LD 

BO,#KEBNEL_SEGHENT 

0311 

00  IS 

03 1C 

5E08 

ELSE 

031E 

0346* 

0320 

93FD 

POSH 

»B15,B13 

0322 

5P00 

C1LL 

GET.DBB.NOHBEB 

0324 

0000* 

1  (BET0S8S:SL1  :DBB  NO)  1 

0326 

97FD 

POP 

B13,dB15 

0328 

76D2 

LD1 

H2,KST.HH_H1NDLE (B13) 

0321 

0000 

032C 

93FD 

POSH 

BB15,  B13 

032E 

5F00 

C1LL 

HH.DEICTIVITE  ! (B1:DBB_ 

0330 

0000* 

1  (H2:-»BU_H1NDLE)  1 

!  (HETlfiO: SOCCESS  CODE) 1 

0332 

5P00 

C1LL 

CONFINEHENT.CHECK 

0334 

0428' 

!  (HO: SOCCESS  CODE)  ! 

0336 

97FD 

POP 

B1 3,BB1 5 

0338 

0108 

CPB 

BLO, iSOCCEEDED 

0331 

0202 

033C 

5E0E 

IF 

EQ  THEN  I0PD1TE  KST1 

033E 

0346* 

0340 

4CD5 

LDB 

KST . H_S EG_NO (B 1 3) , 

0342 

000E 

0344 

FFFF 

FI 

#NOLL_SEG 

FI 

FI 

FI 

0346 

9E08 

BET 

0348  END  TEBHIN1TE 
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0  348 


SH  S HAP  IN 


PROCEDURE 


1  ****************************1 

!  CHECKS  VALIDITY  OF  SNAP  IN  1 

!  REQUEST  AND  CALLS  ! 

!  UH_SiAP_IN  IP  VALID  ! 

1 ****************************1 
!  BEGISTEB  OSE  I 

!  PABAHETEBS  ! 

!  HI  :SE6HENT  NO  (INPUT)  ! 

!  BO  :SUCCESS~*CODE  (BET)  ! 

!  LOCAL  USE  ! 

!  R7 : KST  REC  INDEX  ! 

!  B3 : ACCESS  HODE  ! 

!  B6:CONSTANT  STORAGE  ! 

1  B13:-KST  1 

I  **************************41*1 

ENTRY 

0348  A117  LD  B7,R1  ! COPY  OP  SEG  #1 

034 A  0307  SUB  B7#*NR  OP  KSEGS 

! CONVERT  SEG*  TO  KST  INDEX1 

034C  000A 

0 34E  1906  HULT  RR6,#SIZEOF  KST  BEC 

10PPSET  TO  KST  BBC! 

0350  0010 

0352  93P1  PUSH  9R15,B1  (SAVE  SEGBENTft ! 

0354  93P7  PUSH  9815,87 

0356  2101  LD  R1,*KST  SEG  NO 

0358  0002 

035A  5P00  CALL  ITC  GET_SEG_PTB  !H1:KST_SEG  NO! 

035C  0000* 

035E  A10D  LD  R13,R0  1-KST! 

0360  97P7  POP  R7 , 9R 15 

0362  97P1  POP  R 1 , 9B 1 5  ! RETRIEVE  SEGMENT#! 

0364  817D  ADD  R13,R7  ! ADD  OPFSET  TO  KST  BASE  ADDS ! 

0366  2106  LD  R6,#NULL_SEG 

0368  PPFP 

036A  4ADE  CPB  RL6,KST. H_SEG_NO (B13) 

036C  000E 

036E  5B0E  IF  EQ  THEN 

0370  037A* 

0372  2100  LD  RO, #SEGHENT_NOT_KNQHN 

0374  001C 

0376  5E08  ELSE 

0378  03B8 • 

037A  2106  LD  R6,*TBUE 

037C  0001 

0  37E  4ADE  CPB  BL6 ,KST.IN_COBE  (B13) 

0380  0009 

0382  5E0E  IP  EQ  THEN 
0384  038E' 

0386  2100  LD 


BO,* SUCCEED ED 
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0388  0002 

038A  5208  2LSE 
038C  03B8* 

0382  93FD  POSH  3R15,H13  ISA7E  KS7  BEC  ADDS! 

0390  5F00  CALL  G2T  DBS  ROBBER  !B1:(BEI)DBa  MO! 

0392  0000* 

0394  97 PD  POP  B13tBfi15 

0396  76D2  LDA  R2,KST. MB  HAMDLE(R13) 

0398  0000 

039A  60DB  LDB  BL3, KST. ACCESS  BODE  (B13) 

039C  0008 

039E  93PD  POSH  dB15,B13  1SAVE  SEG  KST  BEC  ADDB! 

03 AO  5P00  CALL  HH  SWAP  III  !  B1  :DBB  MO  ! 

03A2  0000* 

!  B2:  -*BB  HAMDLBI 
!B3: ACCESS.HODE! 

ISO:  (BET)  SUCCESS  CODE! 

03A4  5P00  CALL  COMPIMEHEMT..  CHECK 

!  (RO:  SUCCESS  CODE)! 

03A6  0428* 

03A8  97FD  POP  R13,§B15 

03 AA  0A08  CPB  RLO, tSOCCEBDED 

03AC  0202 

03AE  5202  IP  EQ  THEM 

03B0  03B8* 

03B2  4CD5  LDB  KST.IH_COBE  (B13) , #TBOE 

03B4  0009 
03B6  0101 

PI 

PI 

FI 

0388  9208  RET 

03BA  EMD  SM  SWAP  IM 
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03B& 


SB  SWAP  OUT 


PROCEDURE 


t  *****************************5 

CHECKS  VALIDITY  OP  SWAP  OUT  ! 
!  REQUEST  AMD  CALLS  I 

!  MM_SHAP_OUT  IP  VALID  ! 

i  ***************************** J 

!  RESISTER  USE  ! 

!  PARAMETERS  ! 

!  HI :SEGMENT  NO  ! 

!  RO  zSUCCESS  CODE  (RET)  ! 

!  LOCAL  USE  ! 

!  R7:KST  REC  INDEX  J 

!  R6:CONSTANT  STORAGE  1 

!  HI  3:  -»KST  1 

j  *****************************j 


03BA 

A117 

ENTRY 

LD 

R7  ,  R 1  1  COPY  OP  SEG  *! 

03BC 

0307 

SUB 

R7,*NR  OP_KSEGS 

03BE 

03C0 

OOOA 

1906 

{CONVERT  SEG*  TO  KST  INDEX! 

MULT  RR6 , iSIZEOF  KST_REC 

03C2 

03C4 

0010 
93P 1 

10PPSET  TO  KST_REC ! 

PUSH  3R15,R1  ISAVE  SEGMENT*! 

03C6 

93F7 

PUSH 

9R15,R7 

03C8 

2101 

LD 

R1,#KST_SEG.NO 

03CA 
0  3CC 

0002 

5F00 

CALL 

ITC_GET_S£G_PTR  !R1:KST_SEG_ 

03CE 

03D0 

0000* 

A10D 

LD 

R13,R0  !  •'KST ! 

03D2 

97P7 

POP 

R7,«R15 

03  D4 

97  PI 

POP 

R1 ,  2R15  'RETRIEVE  SEGMENT#! 

03D6 

817D 

ADD 

R13,R7  ! ADD  OFFSET  TO  KST 

03D8 

2106 

LD 

BASE  ADDS! 

R6 , #NULL_SEG 

03DA 
0  3DC 

PPPP 

4ADE 

CPB 

RL6 ,KST . M_SEG_NO (HI  3) 

03DE 

03E0 

OOOE 

5E0E 

IP 

EQ  THEN 

03E2 

03E4 

Q3EC' 

2100 

LD 

RQ,#SEGMENT_NOT_KNOBN 

03E6 

03E8 

00  1C 
5E08 

ELSE 

0  3EA 
03EC 

04  26* 
2106 

LD 

R6 , #P ALSE 

0  3EE 
03P0 

0000 

4ADE 

CPB 

RL6,  KST.IN_CORE  (R13) 

03P2 

03P4 

0009 

5E0E 

IP 

EQ  THEN 

03P6 

03P8 

0400' 

2100 

LD  RO,  #SUCCEEDED 
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0  3PA 

0002 

03  PC 

5E08 

ELSE 

03PE 

0426* 

0400 

93PD 

POSH 

8R15,R13  ISAVE  KSX  REC  ADDR 

0402 

5P00 

CALL 

GET_D8H_N OHBER  JR1:(R£T)DBR 

0404 

0000* 

0406 

97PD 

POP 

R 1 3, 8R1 5 

0408 

76D2 

LDA 

R2,KST.  MN_HANDLE(R13) 

040& 

0000 

040C 

93PD 

POSH 

3R 15 ,E1 3  1SA7E  SES  KST  REC 

040E 

5P00 

CALL 

HH_SHAP_OUT  !S1:DBR_NO! 

0410 

0000* 

!R2: 

HANDLE! 

ISO: 

(RET) SUCCESS  CODE! 

0412 

5P00 

CALL 

confinehentZcbeck 

!  (RO 

:SUCCESS_CODE) ! 

0414 

0428* 

0416 

97PD 

POP 

R13,8R15 

0418 

0A08 

CPB 

RLO, iSUCCEEDED 

04  1 A 

0202 

04  1C 

5E0E 

IP 

EQ  THEN 

04  IE 

0426* 

0420 

4CD5 

LDB  KST.I'i  CORE  (R13) , #P ALSE 

0422 

0009 

0424 

0000 

0426  9E08 
0428 


PI 

PI 

PI 

RET 

END  SM  SNAP  OUT 


t 


0428 


CONFINEMENT  CHECK  PROCEDURE 

•  SERVICE  ROUTINE  TO  VERIFY 
1  CONFINEMENT  IS  NOT  VIOLATED 
»HE»  MEN  MG 8  SUCCESS  CODE  IS 
RETURNED  TO  SUPERVISOR. 

***************,„,  ^^^^^^ 

REGISTER  USB: 

PARAMETERS 

RO:SOCCBSS_CODE 


0428  0B00 

042A  000A 
042C  5E0E 
042E  0438* 
0430  5FOO 
0432  059A 
0434  5208 

0436  04 84* 
0438  0B00 
043A  000B 
043C  5EQB 
043E  0448* 
0440  5P00 
0442  059A 
0444  5E08 

0446  04B4* 
0448  OBOO 
044A  0017 
044C  5E0E 
044E  0458* 
0450  5F00 
0452  059A 
0454  5208 

0456  0484 ' 
0458  OBOO 
045A  0014 
045C  5E0B 
0452  0468* 
0460  5F00 
0462  05 9 A 
0464  5E08 

0466  04B4* 
0468  OBOO 
046A  OOOC 


ENTRY 
IF  RO 

CASE  t LEAF^S EG  EXISTS  THEN 
CALL  MONITOR 


CASE  #NO_L£AF  EXISTS  THEN 
CALL  MONITOR 


CASE  ♦  ALIAS_DQES  NOT  EXIST  THEN 
CALL  MONITOR 


CASE  #NO__CHILD  TO  DELETE  THEN 
CALL  MONITOR 


CASE  #G_AST_F0LL  THEN 
CALL  MONITOR 
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046C 

5S0E 

046E 

0478* 

0470 

5F00 

0472 

0S9A 

0474 

5E08 

0476 

04B4* 

0478 

0B00 

047A 

000D 

047C 

5E0E 

047E 

0488* 

0480 

SFOO 

0482 

05  9 A 

0484 

5E08 

0486 

04B4* 

0488 

0B00 

048A 

0010 

048C 

5E0E 

048E 

0498' 

0490 

SFOO 

0492 

059A 

0494 

5E08 

0496 

04  B4* 

0498 

OBOO 

049A 

0011 

049C 

5E0E 

049E 

04A8* 

04A0 

5F00 

04A2 

059A 

04A4 

5E08 

04A6 

04B4 ' 

04A8 

OBOO 

04AA 

0015 

04AC 

5E0E 

04AE 

04  B4 ' 

04B0 

5F00 

0UB2 

05  9 A 

04B4 

9E08 

04B6 

CASE  #L  AST  FULL  THEN 
CALL  MONITOR 


CASE  #LOCAL_MEHOfi*_FULL  THEN 
CALL  HONITOfi 


CASE  iGLOBAL.MEHORY.FULL  THEN 
CALL  MONITOR 


CASE  #SEC  STOR  FULL  THEN 
CALL  MONITOR 


FI 

RET 

END  CONFI NEMENT.CHECK 


END  SEG  MGR 
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Appendix  I 

NON -DISCRETION ART  SECOBITX  LISTINGS 
Z8000ASM  2.02 

LOC  OBJ  CODE  STMT  SOOBCE  STATEMENT 

SLISTON  STTY 
NDS  NODDLE 

CONSTANT 

TBOE  : =1 

PALSE  : =0 

INTERNAL 

{SECTION  ACC  CLASS.. DC L  SNOTE:  IS  AN  OVERLAY , 

IE  NO  ALLOCATION 
OF  MEMORY ! 

SABS  0 

0000  ACCESS  CLASS  RECOBD  [LEVEL  INTEGER 

CAT  INTEGER] 

GLOBAL 

SSECTION  NDS_PROC 

0000  CLASSJSQ  PROCEDURE 

(  ****************************** l 

!  PASSED  PABANETERS  ! 

1  RB2  *  CLASS  1  ! 

!  HR 4  =  CLASS2  ! 

1  RETURNED  i 

1  HI  *  CONDITION_CODE  I 

] ****************************** | 


ENTRY 

0000 

9042 

CPL 

RR2, RB4 

0002 

5B0E 

IP 

EQ 

THEN 

0004 

OOOE* 

0006 

2101 

LD 

R1, #TR0E 

0008 

0001 

000A 

5E08 

ELSE 

OOOC 

0012* 

000E 

2101 

LD 

R  1 , #P ALSE 

0010 

0000 

PI 

0012 

9E08 

RET 

0014 

END  CLASS 

_EQ 
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0014  CLASS  GE  PBOCEOOBE 


! 

! 

PISSED 

*********************** l 

PA8AMETEBS  1 

! 

8B2  = 

CLASS  1  l 

J 

BB4  = 

CLASS2  i 

! 

BETOBNED  PABANETEfi  < 

! 

! 

B1  * 

CONDITION.CODE  1 

*********************** { 

ENTBT 

0014 

91P2 

PUSHL 

9B15,RB2  (POSE  CLASS1  ON  STACK- 

-BSP SB  BY  ADDBI 

0016 

A1PD 

LD 

813,815  !  CLASS1  ADDB  1 

0018 

91P4 

POSHL 

3815,834 

0011 

A1FE 

LD 

814,315  !  CLASS2  ADDB  ! 

001C 

31 E7 

LD 

37,814  (#  ACC  ESS  CLASS.  CAT) 

1  CAT 2  IN  B7  1 

00  IE 

0002 

0020 

45D7 

OB 

87,  ACCESS  CLASS. CAT  (B13) 

tCATI  OB  CAT2,  B71 

0022 

0002 

0024 

4BD7 

CP 

87  ,  ACC ESS_C LASS. CAT  (B 13) 

!CAT1* (CAT1  OB  CAT2) ? ! 

0026 

0002 

0028 

5E0E 

IP  EQ 

THEN 

0021 

0048* 

002C 

6106 

LD 

B6 v ACCESS  CLASS. LEVEL (Hi 3) 

1 LETEL1 1 

002E 

0000 

I 

COHPABE  LEV  EL 1  WITH  LEV EL2  1 

0030 

4BE6 

CP 

B6  #ACCESS_CLASS. LEVEL (R14) 

0032 

0000 

0034 

5E01 

IP 

GE  THEN  ! LEV ELI  GE  LEVEL2J 

0036 

0040* 

0038 

2101 

LD  B1,*TB0E 

0031 

0001 

003C 

5E08 

ELSE 

003E 

0044* 

0040 

2101 

LD  BI'IPALSE 

0042 

0000 

PI 

0044 

5E08 

ELSE 

0046 

004C' 

0048 

2101 

LD 

81, IPALSE 

0041 

0000 

PI 

004C 

95P4 

POPL 

884,381 5 

004E 

95P2 

POPL 

382,3315  1 BESTOBE  STACK! 

0050 

9808 

BBT 

0052 

END  CLASS  SE 

END 

NDS 
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Appendix  J 

HE HOB Y  HAMAGEB  LISTINGS 


Z8000ASM  2.02 

LOC  OBJ  CODE  STMT  SOUBCE  STATEMENT 

SLISTON  $TTY 

MM..  PROCESS  MODULE 

1  YESS.  1.9  ! 

CONSTANT 

RETORN_TO_MONITOR  S*  XA902  ! HBUG  BEEHTBI! 


COUNT  :*  10 
TIME  :=*  500 

NR_OF_HOSTS 

*  2 

G  AST'lIMIT 

*  10 

S  AST  FULL 

*  12 

FREE  ENTRY 

=  XEEEEEEEE 

TRUE 

»  XBBBB 

FALSE 

*  XCCCC 

SPACE 

»  X20 

DASH 

=  X2D 

IO_HGR 

:  =  X60 

FILE_MGR 

*  X40 

HEM  MGR 

*  XQQ 

FM  ENTRY 

*  X4A00 

10  ENTRY 

*  X4E00 

CREATE  ENTRY  CODE 

s  50 

INVALID  MMGR  CODE 

3  go 

DELETE  ENTRY  CODE 

3  51 

ACTIVATE  SEG"C0DE 

*  52 

DEACTIVATE  SEG  CODE 

*  53 

SWAP_IN_SEG_CODE 

3  54 

SWAP* OUT  SEG  CODE 

=  55 

SUCCEEDED 

*  2 

STK_SIZE 

*  1 

TOP_S ECRET 

=  4 

SECRET 

=  3 

CONFIDENTIAL 

*  2 

UNCLASS 

*  1 

EMPTY 

*  0 

CRYPTO 

*  1 

-  387  - 

NATO 

NUCLEAR 


*  2 
*  4 


TYPE 

ADDRESS  HOED 

B_A8RAY  ABBAY[ 3  HOBO] 


G_AST— BBC  BECOBD 


UNIQOE_ID 

LONG 

GLOBAL  AOOB 

AOOBESS 

P  L  ASTB  NO 

HOBO 

PLAG_BITS 

HOBO 

G_ASTE_PAR 

HOBO 

NO  ACT  IN  NEE 

HOBO 

NO  ACT  DEP 

BYTE 

SI2B1 

BYTE 

PG  TBL  LOC 

AOOBESS 

ALIAS  TBL  LOC 

AOOBESS 

SEQUENCER 

LONG 

EVENT  1 

LONG 

EVE NT 2 

LONG 

EXTERNAL 
SIGNAL 
HAIT 
TC  INIT 
SET  CPU  NO 
CREATE_PROCESS 
SNOCHB 
SNDBSG 
S  NDCRLF 


PROCEDU BE 
PROCEDURE 
PBOCEOUBE 
PBOCEODBE 
PBOCEOUBE 
PBOCEOUBE 
PBOCEOUBE 
PBOCEOUBE 


G_AST_LOCK  HOBO 

G_AST  ABHAY[G_AST_LIEIT  G  AST  BEC] 
GLOBAL 

SSBCTION  BN.DATA 

HE  ENTRY  LABEL 


388 


INTERNAL 


!  *  *  *  *  MESSAGES  *  *  *  *  I 

0000 

08 

28 

10  ARRAY  [*  BYTE]  :»  **08 (FOR  10) • 

0002 

46 

4F 

0004 

52 

20 

0006 

49 

4F 

0008 

29 

0009 

08 

28 

PB  ARRAY  C*  BYTE]  ;«  **08(F0R  FB)  • 

000B 

46 

4F 

OOOD 

52 

20 

OOOP 

46 

40 

0011 

29 

0012 

12 

4B 

SB  BSG  1 

ARRAY  [*  BYTE]  :«  1 %12KBBNEL  *  SIGNALLER* 

0014 

45 

52 

0016 

4E 

45 

0018 

4C 

20 

001 A 

3D 

20 

001C 

53 

49 

001E 

47 

4B 

0020 

41 

4C 

0022 

4C 

45 

0024 

52 

0025 

10 

4D 

CREATE  BSG 

ARRAY  [*  BYTE]:*  **10BB:  CREATE_ENTRY * 

0027 

4D 

3A 

0029 

20 

43 

002B 

52 

45 

002D 

41 

54 

002F 

45 

5P 

0031 

45 

4E 

0033 

54 

52 

0035 

59 

0036 

10 

4D 

DELETE  BSG 

ARRAY  £*  BYTE]  :*  **10BB:  DELETE_ENTR Y* 

0038 

4D 

3A 

003& 

20 

44 

003C 

45 

4C 

003E 

45 

54 

0040 

45 

5F 

0042 

45 

4E 

0044 

54 

52 

0046 

59 
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0047 

OC 

40 

ACTIVATE. HSG 

ARRAY  [*  BYTE]  :»  'XOCRH:  ACTIVATE* 

0049 

40 

3A 

004B 

20 

41 

004D 

43 

54 

004P 

49 

56 

0051 

41 

54 

0053 

45 

0054 

OE 

40 

DEACTIVATE  SSG 

ARRAY  [*  BYTE]  :*  ' XOEHH:  DEACTIVATE* 

0056 

40 

3A 

0058 

20 

44 

005A 

45 

41 

005C 

43 

54 

005E 

49 

56 

0060 

41 

54 

0062 

45 

0063 

OB 

40 

SWAP  IN  SSG 

ARRAY  [*  BYTE]  :*  ' XOBBB :  SBAP.IH* 

0065 

40 

3A 

0067 

20 

53 

0069 

57 

41 

006B 

50 

5P 

006D 

49 

4E 

006P 

OC 

40 

SNAP  OOT  SSG 

ARRAY  f*  BYTE]  :=  • XOCSS:  SBAP.OUT* 

0071 

4D 

3A 

0073 

20 

53 

0075 

57 

41 

0077 

50 

5P 

0079 

4P 

55 

007B 

54 

007C 

OC 

49 

ERROR  BSG 

ARRAY  [*  BYTE]  :*  • XOCINVALID  CODE* 

007E 

4E 

56 

0080 

41 

4C 

0082 

49 

44 

0084 

20 

43 

0086 

4P 

44 

0088 

45 

0089 

02 

00 

RET  VALUES 

ARRAY  (*  B'TE]  :=  [2,0,0,0,0,16,0,17, 

008B 

00 

00 

0080 

00 

10 

008F 

00 

11 

0091 

00 

03 

0093 

00 

01 

0095 

00 

30 

0097 

00 

00 

t,0,4 

099A 

MH.HSG  ARRAY  ARRAY  [  8  BORO  ] 

00  AA 

SENDER-  BORO 
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BB  BEJ 


SABS  0 

ISO  MB MOBY  ALLOCATED;  USED 
POE  PA BA BET EE  TEMPLATE  ONLY! 


0000 


C 


] 


ACTIYATE.ABG  BECOBD 
CODE  HOED 

DBB  HOED 

HANDLE  H  ABBAI 

ENTBY  NO  BYTE 

SEG  NO  BYTE 


SABS  0 

1  NO  NEHOBY  ALLOCATED;  OSED 
FOB  PABAMETEfi  TEMPLATE  ONLY! 


0000 


0000 


BETJTAL 
C  CODE1 
FILLEB 
MM  HANDLE 
CLASS 
SIZE 
FILLEB 1 

1 

SABS  0 
AB6  LIST 
[  BEG 
IC 

CPU_ID 

SAC 

PBI 

OSB  STK 
KEB_STK 


BECOBD 
BYTE 
BYTE 
H  ABBAY 
LONG 
HOED 
HOED 


BECOBD 

ABBAYC 13  HOED] 

HOED 

BO  ED 

LONG 

HOBD 

BQBD 

HOBD 


1 
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{SECTION  NH_PROC 


oooo  hh_hain  pbocedube 

ENTRY 

aa.ENTBI: 


!  INITIALIZE  G_AST  1 

0000 

4008 

CLR 

G.AST.LOCK 

0002 

0000* 

0004 

2102 

LO 

B2 ,  #1 

0006 

0001 

0008 

2101 

LO 

HI,  *0 

OOOA 

0000 

000C 

1404 

LDL 

HR 4,  #PREE_ENTR Y 

OOOE 

EEEB 

0010 

SEES 

00 

0012 

SD14 

LDL 

G_AST. ONIQUE_ID (B 1)  , 

0014 

0000* 

0016 

A920 

INC 

R2,  #1 

0018 

0B02 

CP 

R2,  #G__  AST_LIH IT 

001A 

OOOA 

001C 

5E02 

IF  GT  ! END  OF  G  AST!  THEN 

001E 

0024* 

0020 

5E08 

EXIT 

FI 

0022 

002A' 

0024 

0101 

ADD 

R1,  tSIZEOF  G_ASI_BEC 

0026 

0020 

0028 

E8F4 

00 

!  RESERVE  FIBST  ENTBY  IN 
G_AST  FOB  BOOT  ! 


002A 

2101 

LD 

R1  ,  tO 

002C 

0000 

002E 

1404 

LOL 

RR4,  f-1 

0030 

FFFF 

0032 

FFFF 

0034 

5014 

LDL 

G_AST. UNIQUE JLD  (SI)  ,  BB4 

0036 

0000* 

0038 

5F00 

CALL 

GET_CPU_NO  I  RETURNS: 

003A 

0000* 

B1:  CPU  t 

R2:  •  VP'S! 

003C 

93F1 

POSH 

iR  15,  HI  ISAVE  CPU  »f 

003E 

5F00 

CALL 

TC  INIT 

0040 

0000* 

!  OSER/HOST  t  ! 

0042 

2100 

LD 

SI  3 ,  #0 

0044 

0000 

f  INITIALIZE  OSEBS  ! 

DO 

0046 

A900 

INC 

R13,  *1 

0048 

OBOO 

CP 

R13,  >NR_OP_HOSTS 

004A 

0002 

IF  ST  ! ALL  HOSTS  INITIALIZED! 

004C 

5E02 

THEN 

EXIT 

004E 

0054* 

0050 

5E08 

0052 

OOB8  * 

FI 

!  CREATE  FM  PROCESS  ! 

0054 

21P0 

LD 

HO,  8R1 5  ! RESTORE  CPO  *! 

0056 

030P 

SUB 

H  15,  iSIZEOF  ARG.LIST 

0058 

0028 

!  SETS 

1  ARGUHENT  LIST  IN  STACK! 

005A 

A1F1 

LD 

R  1 ,  R15 

005C 

6P10 

LD 

ARG  LIST. CPU  ID(fil),  RO 

005E 

001C 

! LOAD  INITIAL  REGISTER  PARAMETERS 

FOR 

PS  PROCESS  (SIBOLATED) 

R13 

DENOTES  USER  *  ! 

0060 

5C19 

LDH 

ARG_LIST.REG  (R  1)  ,  R2,  >13 

0062 

020C 

0064 

0000 

0066 

2102 

LD 

R2 ,  >FH_ENTRX 

0068 

4A00 

006A 

6F12 

LD 

ARG_LIST.IC(R1) ,  H2 

006C 

00 1 A 

006E 

2102 

LD 

H2 ,  tSECRET 

0070 

0003 

0072 

8D38 

CLR 

R3 

0074 

0503 

OR 

H  3 ,  #CR YPTO 

0076 

0001 

0078 

5012 

LDL 

ARG_LIST.SAC  (HI)  ,  RR2 

007A 

00  IE 

007C 

4D15 

LD 

ARG_LIST.PRI  (R1)  ,  #2 

007E 

0022 

0080 

0002 

0082 

4015 

LD 

ARG_LIST. USR_STK  (R1)  ,  #STK_SIZE 

0084 

0024 

0086 

0001 

0088 

4D15 

LD 

ARG_LIST.KER_STK  (R1)  ,  >SIK_SIZE 

008A 

0026 

008C 

0001 

008E 

A11E 

LD 

R 14,  R1 

0090 

93F0 

POSH 

iR 15,  R  13 

0092 

5FOO 

CALL 

CREATE.. PROCESS  !R14:  ARG  PIRI 

0094 

0000* 

0096 

97FD 

POP 

R 13,  RR 15 

!  CREATE  10  PROCESS  i 
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0098 

A1P1 

LO 

R1f  R15  IRESTORE  ARGUMENT  PTR! 

!LOAD  INITIAL  REGISTER  PARAMETERS 

FOR  10  PROCESS  (SIMULATED) 

R 1 3  DENOTES  USER  #  i 

009A 

5C19 

LDH 

A RG_LIST.  REG  (R 1)  ,  R2,  #13 

009C 

020C 

009S 

0000 

00  AO 

2102 

LD 

R2,  #IO_BNTRY 

00A2 

4E00 

00A4 

6F12 

LD 

ARG_LIST.IC (HI)  ,  R2 

00A6 

00 1 A 

00A8 

A11E 

LD 

R 14,  HI 

OOAA 

93PD 

POSH 

SR  15,  R 13 

00  AC 

5P00 

CALL 

CREATE.. PROCESS  IR14:  ARG  PTR! 

OOAE 

0000* 

OOBO 

97PD 

POP 

R 13,  SR  15 

00B2 

010F 

ADD 

R 15,  ISIZEOF  ARG_HST 

00B4 

0028 

00B6 

E8C7 

OD 

!  REMOVE  CPU  #  FROM  STACK  < 

00B8 

97F0 

POP 

RO,  SR  15 

DO  !** 

DO  FOREVER  **! 

OOBA 

7608 

LDA 

R8,MM_MSG_ARR AY  0 

OOBC 

009A* 

OOBE 

5F0Q 

CALL 

WAIT 

OOCO 

0000* 

00C2 

6F01 

LD 

SENDER,  R 1  ISAVE  SIGNALING  PROC  *! 

00C4 

OOAA* 

OOC6 

2103 

LD 

R3, #50 

00C8 

0032 

OOCA 

5F00 

CALL 

MM_PBINT_BLANKS 

OOCC 

030C* 

OOCE 

2102 

LD 

R2, #MM_MSG_ 1 

OODO 

0012* 

0002 

5F00 

CALL 

SNDMSG 

0004 

0000* 

0006 

6101 

LD 

R1, SENDER 

00D8 

OOAA* 

IF 

HI 

OOOA 

0B01 

CASE  #IO_MGB  THEN  LD  R2,*I0 

OODC 

0060 

OODB 

SEOE 

OOEO 

OOEE* 

00E2 

2102 

00E4 

0000' 

00E6 

5F00 

CALL  SNDHS6 

00B8 

0000* 

OOEA 

5B08 

CASE  IFILE  MGR  THEN  LD  R2,*FM 

00  EC 

OOFE' 

OOEE 

0B01 

OOPO 

0040 

OOP2 

5E0E 
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00F4 

00F6 

OOFS 

OOFE' 

2102 

0009* 

OOFA 

OOFC 

5F00 

0000* 

* 

PI  " 

CALL  SNDMSG 

OOFE 

Old 

5F00 

0208' 

CALL 

MB_DELAT 

0102 

0104 

5F00 

0000* 

CALL 

SHDCHLF 

0  106 
0108 

2103 

0032 

LD 

B3,#50 

0  1 0A 
010C 

5F00 

030C' 

CALL 

SM_PRINT_ BLANKS 

0  1 0E 
0110 

6101 

009A* 

LO 

R  1  r  Hfl_MSG_ARB AY  0 
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0112  0B01 
0114  0032 
0116  SEOE 
0113  0122' 

oi n  spoo 

011C  019E* 
011E  5B08 
0120  0176* 
0122  0801 
0124  0033 
0126  5E0E 
0128  0132' 
012A  SPOO 

oi2c  one* 

012E  5E08 
0130  0176* 
0132  OBO 1 
0134  0034 
0136  SEOE 
0138  0142* 
013A  SPOO 
013C  01  BA ' 
013E  5E08 
0140  0176* 
0142  0B01 
0144  0035 
0146  SEOE 
0148  0152* 
0 14A  5 POO 
0 14C  029E* 
0 14E  5E08 
0150  0176* 
0152  0B01 
0154  0036 
0156  5E0B 
0158  0162* 
0 15A  5P00 
015C  02AC* 
0 15E  5E08 
0160  0176* 
0162  OBOI 
0164  0037 
0166  5E0B 
0168  0172* 
0 16A  5F00 
0 16C  02CA' 
016E  5E08 
0170  0176* 
0172  2102 
0174  007C* 


IP  B1 

CASE  ACBEATE.ENTBY.CODB  THEM 

CALL  CBEATE.EMTBY 
CASE  iDELETE  EVTBT  CODE  THEM 


CALL  DELETE. EMTBT 
CASE  iACTI VATE.SE6.C0DE  THEM 

CALL  ACTIVATE 

CASE  iDEACIIVATB.SEG.CODE  THEN 

CALL  DEACTIVATE 
CASE  ISWAP.IM.S EG .CODE  THEN 

CALL  S1AP.IN 

CASE  ISMAP.OOT.SEG.CODE  THEN 

CALL  SHAP.OOT 

ELSE 

LD  B2 , iEBBOB.HSG 

PI 

-  396  - 


0176  5P00  CALL  SNDHSG 

0178  0000* 

017A  5P00  CALL  SB  DELAY 

017C  02D8* 

017B  5P00  CALL  SNDCBL? 

0180  0000* 

0182  2103  LD  83, #75 

0184  004B 

0186  5P00  CALL  HM.PBINT  LIME 

0188  02P4* 

018A  5P00  CALL  SMDCSLF 

018C  0000* 

!  **  SIGNAL  (SENDER,  • DONE* )  **  ! 
0 18E  6101  LD  81,  SENDEB 

0190  OOAA' 

0192  7608  LDA  88, MM  MSG  ABBA!  0 

0194  009A* 

0196  5P00  CALL  SIGNAL 
0198  0000* 

019A  E88P  OD  !  **  REPEAT  FOREVER  **  J 

019C  9E08  BET 

019E  END  MM. MAIM 

0 19E  CREATE.ENTBY  PROCEDURE 

ENTRY 

019E  7608  LDA  88 , MM  MSG  ARRAY  0 
0 1 AO  009A' 

01A2  0C85  LDB  8B8, •SUCCEEDED 

01A4  0202 

01A6  2102  LD  8  2,  #CBEATE  MSG 

01A8  0025* 

0 1 AA  9E08  RET 

0 1 AC  END  CREATE.ENTBY 

01  AC  DELETB.SMTRY  PROCEDURE 

ENTRY 

9 1 AC  7608  LDA  R8,HH  MSG  ABBAY  0 

01AB  009 A' 

01  BO  0C85  LDB  98 8, #SUCCEEDED 

0 1B2  0202 

01B4  2102  LD  B2,#DELETE  MSG 

01B6  0036' 

01B8  9E08  BET 

01 BA  END  DELETE  ENTBY 


01BA 

ACTIVATE  PBOCEDUBE 

!  B8:  ARGUMENT  PTB  i 

ENTRY 

0 1BA 

7608 

LOA 

R8 ,  HH_HSG_ABBAY  0 

0  tBC 

009A* 

01  BE 

6182 

LD 

R2  r  ACTIVATE  ABG*  HANDLE  2  (B8> 

10NIQ0E  10! 

01C0 

0008 

0 1C2 

8038 

CLB 

B3 

0  1C4 

608B 

LOB 

BL3,  ACTIVATE_ABG . ENTBY_NG (B8) 

0 1C6 

OOOA 

0  1C8 

030P 

SOB 

HI  5,  VSIZSOP  BET.VAL 

01CA 

0010 

01CC 

A1P8 

LD 

R8,  B15 

0  ICE 

2100 

LO 

BO  ,  *PALSE 

0100 

CCCC 

0102 

2101 

LO 

HI  ,  *0  !G_AST  INDEX! 

0104 

0000 

0106 

2104 

LD 

R4 ,  #1  I NB  OP  ENTRIES  SEARCHED! 

0  1D8 

0001 

SEAHCHJ5_AST: 

00 

0  IDA 

5012 

CPL 

RR2,  G_AST.  UNIQOE_ID  (B 1) 

0  10C 

0000* 

01DS 

5  SOS 

IP 

EQ  ! SEGMENT  IS  ACTIVEI  THEN 

0 1 EO 

01EA' 

0 1E2 

2100 

LD 

BO,  *TROE 

0  1E4 

BBBB 

01E6 

5E08 

EXIT  EBON  SEABCU  G_AST 

0  1E8 

01FE* 

PI 

0  ISA 

A940 

INC 

84/  *1 

01  EC 

0B04 

CP 

R4 ,  #G_AST_LIHIT 

0 1EE 

OOOA 

01P0 

5B02 

IP 

GT  (END  OP  G_AST!  THEN 

0 1F2 

01P8' 

01F4 

5E08 

EXIT  FBOB  SEARCH  S  AST 

01F6 

01PE* 

PI 

0 1P8 

0101 

ADD 

B 1 #  tSIZEOP  G.AST.BEC 

0  1PA 

0020 

01PC 

E8EE 

00 

0 1PE 

OBOO 

CP 

BO*  fPALSE 

0200 

CCCC 

IP  EQ 

ISEGHENT  NOT  ACTIVE! 

0202 

5E0E 

THEN 

0  204 

0266* 

0206 

2100 

LD 

80/  #1 

0208 

0001 

020A 

2101 

LO 

HI,  *0 
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020C  0000 


PIND_FREE  ENTRY: 

DO 

020E  1404  LDL  RR4,  #FBEE  ENTRY 

0210  EEEE 
0212  SEES 

0214  5014  CPL  RR4,  G  1ST. UNIQUE  ID(R1) 

0216  0000* 

0218  5B0E  IP  EQ  ! ENTRY  IS  1PAILABLE!  THEN 

02  1 A  0220' 

0  21C  5E08  EXIT  PRON  PIND  PREE  ENTRY 

02 IE  0234* 

PI 

0220  A900  INC  BO,  *1 

0222  0B00  CP  RO,  #G  AST  LIMIT 

0224  OOOA 

0226  5E02  IP  GT  I  END  OP  G  AST!  THEN 

0228  022E* 

022A  5E08  EXIT  PROM  FIND  FREE  ENTRY 

022C  0234* 

PI 

022E  0101  ADD  HI,  #SIZEOP  G  AST  REC 

0230  0020 

0232  E8ED  OD 

0234  OBOO  CP  BO,  *G  AST  LIMIT 

0236  OOOA 

IP  LE  {POUND  FREE  ENTRY! 

0238  5E0A  THEM 

023A  025C* 

023C  5D12  LDL  G_AST. UNIQUE  ID(R1)  ,  RR2 

023E  0000* 

1  ZERO  ALL  SPENT  DATA  ENTRIES  ! 
0240  1404  LDL  R84,  *0 

0242  0000 
0244  0000 

0  246  5D14  LDL  G_AST.  SEQUENCER  (R1)  .  RR4 

0248  0014* 

024A  5D14  LDL  G_AST. EPENT1 (R1) ,  RR4 

024C  0018* 

024E  5D14  LDL  G_AST. EPENT2 (R1) ,  RR4 

0250  001C* 

0252  4C85  LDB  RET_VAL.CQDE1  (R8) ,  tSOCCEEDSD 

0254  0000 
0256  0202 

0258  5E08  ELSE 
0  25A  0262* 

025C  4C85  LDB  RET_YAL.C0DE1 (R8) ,  *G  AST  POLL 

025E  0000 
0260  OCOC 

PI 

0262  5E08  ELSE  ! SEGMENT  ACTIPE! 
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0264 

026C* 

0266 

4C85 

LDB 

BET  VAL.C00E1  (B3)  ,  iSUCCEEDED 

0268 

0000 

026A 

0202 

FI 

0  26C 

5D82 

LDL 

BET_VAL. BH_HAMDLE  0  (B8) , 

BB2 

026E 

0002 

0270 

6781 

LO 

BETJTAL.  EM.HAHDLB  2  (B8)  , 

B  1 

0272 

0006 

0  274 

1404 

LDL 

BB4,  #*30001 

0276 

0003 

0278 

0001 

027A 

5D84 

LDL 

BET  JTAL. CLASS  (B8)  ,  BB4 

0  27C 

0008 

027E 

4085 

LD 

BET_VAL. SIZE (B8)  ,  *1 

0280 

oooc 

0282 

0001 

0284 

7689 

LDA 

B9 ,  BET_VAL  (B8) 

0286 

0000 

0288 

7608 

LOA 

B8 ,  HH_HSG_ABBAI  0 

028A 

009A* 

0  28C 

2102 

LO 

B2,  #16 

028E 

0010 

0290 

BA91 

LOIBB 

9B8#  8B9,  B2 

0292 

0280 

0  294 

2102 

LD 

B2V  #ACTI?ATE_8SG 

0296 

0047* 

0298 

010F 

ADO 

B 1 5 ,  #SIZEOF  HET_VAL 

029A 

0010 

029C 

9E08 

BET 

029E 

END  ACTIVATE 
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029E 


DEACTIVATE 


PROCEDURE 


029E 

7608 

ENTRY 

LDA 

R8 , HN_MSG_ARR AY  0 

0  2  AO 
02A2 

009A' 

0C85 

LDB 

§R 8 , iSUCCEEDED 

02A4 

02A6 

0202 

2102 

LD 

R2,#DEACTIVATE_HSG 

02A8 

02AA 

0054* 

9E08 

RET 

02  AC 

END  DEACTIVATE 

02  AC 

SWAP.IN  PROCEDURE 

02AC 

2102 

ENTRY 

LD 

R2 1  #*FP30 

02AE 

02B0 

PP30 

3B26 

OUT 

%FPD2,  R2 

0282 

02B4 

PPD2 

7608 

LDA 

R8 ,  HM_FSG_ARRAI 

0  2B6 
02B8 

009A* 

5P00 

CALL 

WAIT  i R8:NSG  ARRAY! 

0  2BA 
02BC 

0000* 

7608 

LDA 

R8  ,  HH_M  3G_ARR  AY  0 

02BE 
0  2C0 

009A* 

0C85 

LDB 

3R 8,# SUCCEED ED 

02C2 
0  2C4 

0202 

2102 

LD 

R2 , #SHAP_IN_HSG 

02C6 

02C8 

0063* 

9E08 

RET 

02CA 

END  SWAP.IN 
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i  i 


SNAPJJDT 


PROCEDURE 


02CA 


Q2CA  7608 
02CC  0091* 
02CE  0C85 
0200  0202 
02D2  2102 
0204  0Q6F* 
0206  9B08 
0208 


0208  Ha_DELAY  PBOCEDOBE 

*********************** ***********1 

i  PRODUCES  2  SEC  DELAY  I 

j  ********************************* ] 


ENTRY 

LDA 

B8 , HH_HS G_ARB AY  0 

LOB 

§B8  , iSUCCEEOEO 

LD 

R2,#S»AP_OOT,aSS 

BET 

END  SBAP'.OOT 

EHTRY 

02D8 

2102 

LO 

82, 

♦COUNT 

020A 

OOOA 

020C 

2101 

LO 

HI, 

♦TIME 

02DE 

01P4 

00 

02E0 

0B02 

CP 

B2, 

*0 

02E2 

0000 

0  2E4 

5E0E 

I?  EG 

THEN 

EXIT  FI 

02E6 

02EC' 

02E8 

5E08 

02EA 

02P2* 

0  2EC 

AB20 

DEC 

R2 

02EE 

7B1D 

HBEQ 

fil 

02P0 

E8P7 

00 

02P2 

9E08 

RET 

02F4 

END  NN.DELAY 
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02P4 


Ha  PRINT  LINE 


PROCEDURE 


!  PRINTS  LINE  LENGTH 
!  SPEC  IN  R3. 

j  *******************< 


ENTRT 

02P4 

C82D 

LDB 

RLO , 

•  DASH 

DO 

02F6 

0B03 

CP 

83 1 

#0 

0  2F8 

0000 

02FA 

5E0E 

IF  EQ 

THEN 

EXIT 

02FC 

0302* 

02FE 

5E08 

0300 

030A* 

0302 

5F00 

CALL 

S  NDCHR 

0304 

0000* 

0306 

AB30 

DEC 

R3 

0  308 

E8F6 

OD 

030A 

9E08 

RET 

030C  END  HH_PRINT_LIHE 

030C  HH_P HI NT_ BLANKS  PROCEDURE 

{ *********************************] 

!  PRINTS  NUHBER  OF  i 

!  BLANKS  SPEC  IN  R3.  I 

I *********************************  j 


030C 

C820 

ENTRY 

LDB 

RLO, 

030E 

0B03 

DO 

CP 

R3, 

0310 

0312 

0000 
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R3 

0320 
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OD 

0322 

9B08 

RET 

0324 

END  BH 

PRINT! 

END 
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